[SERVER-14785] Unpredictable results around edge cases when setting log levels Created: 04/Aug/14  Updated: 31/Jul/15  Resolved: 08/Oct/14

Status: Closed
Project: Core Server
Component/s: Logging
Affects Version/s: 2.7.4
Fix Version/s: None

Type: Bug Priority: Trivial - P5
Reporter: Andrew Emil (Inactive) Assignee: Matt Kangas
Resolution: Done Votes: 0
Labels: 28qa, community-team
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-15486 Improve setParameter logComponentVerb... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

The parsing of options around setting log levels has some unpredictable results for edge cases.

Case 1:
If you set a negative log level using the new input method the log level gets set to 0. However, if you use the log level to just under the max int value you can get a negative log level to get set. Additionally, if you use a very very large number, nothing gets set at all.

examples:

Using:

--setParameter logComponentVerbosity="{verbosity: -1}"

Sets:

> db.runCommand({getParameter: 1, logLevel:1})
{ "logLevel" : 0, "ok" : 1 }

But using:

--setParameter logComponentVerbosity="{verbosity: 2147438580}"

Sets:

> db.runCommand({getParameter: 1, logLevel:1})
{ "logLevel" : -12, "ok" : 1 }

And using:

--setParameter logComponentVerbosity="{verbosity: 999999999999999999}

Sets:

> db.runCommand({getParameter: 1, logLevel:1})
{ "logLevel" : 0, "ok" : 1 }

Case 2:
If you set log level as 1.9 or 1.1, the level gets interpreted as 1. However, if you set it to 1.999999999999999 the level will be 2.

Using:

--setParameter logComponentVerbosity="{verbosity: 1.999999999999}"

Sets:

> db.runCommand({getParameter: 1, logLevel:1})
{ "logLevel" : 1, "ok" : 1 }

However, using:

--setParameter logComponentVerbosity="{verbosity: 1.9999999999999999999999}"

Sets:

> db.runCommand({getParameter: 1, logLevel:1})
{ "logLevel" : 2, "ok" : 1 }

For context, build info of server I am running:

> db.runCommand({buildinfo:1})
{
        "version" : "2.7.5-pre-",
        "gitVersion" : "6e2f3346f21f8e5de68aa5099317512ef51eb023",
        "OpenSSLVersion" : "",
        "sysInfo" : "Linux localhost.localdomain 3.13.10-200.fc20.x86_64 #1 SMP Mon Apr 14 20:34:16 UTC 2014 x86_64 BOOST_LIB_VERSION=1_49",
        "loaderFlags" : "-fPIC -pthread -Wl,-z,now -rdynamic",
        "compilerFlags" : "-Wnon-virtual-dtor -Woverloaded-virtual -std=c++11 -fPIC -fno-strict-aliasing -ggdb -pthread -Wall -Wsign-compare -Wno-unknown-pragmas -Winvalid-pch -pipe -Werror -O3 -Wno-unused-local-typedefs -Wno-unused-function -Wno-deprecated-declarations -Wno-unused-but-set-variable -fno-builtin-memcmp -std=c99",
        "allocator" : "tcmalloc",
        "versionArray" : [
                2,
                7,
                5,
                -100
        ],
        "javascriptEngine" : "V8",
        "bits" : 64,
        "debug" : false,
        "maxBsonObjectSize" : 16777216,
        "ok" : 1
}



 Comments   
Comment by Matt Kangas [ 08/Oct/14 ]

Setting a logComponentVerbosity level to a negative number is defined per SERVER-5092 to mean "clear and inherit from parent". For the default component, setting it to -1 results in a log level of 0 (as observed above).

The other numeric limits issues noted above are consequences of using BSONElement.coerce<int>. If a BSON NumberLong or NumberDouble is received, it is cast to an int which necessarily results in loss of precision.

https://github.com/mongodb/mongo/blame/r2.7.7/src/mongo/db/commands/parameters.cpp#L355-L356
https://github.com/mongodb/mongo/blame/r2.7.7/src/mongo/bson/bsonelement.cpp#L734-L739
https://github.com/mongodb/mongo/blame/r2.7.7/src/mongo/bson/bsonelement.h#L597-L609

Generated at Thu Feb 08 03:35:59 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.