[SERVER-68838] Explicitly check for NaN when setting log verbosities Created: 15/Aug/22 Updated: 29/Oct/23 Resolved: 09/Nov/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 6.2.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Varun Ravichandran | Assignee: | Varun Ravichandran |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Operating System: | ALL | ||||||||
| Sprint: | Security 2022-09-19, Security 2022-10-03, Security 2022-10-17, Security 2022-10-31, Security 2022-11-14 | ||||||||
| Participants: | |||||||||
| Description |
|
Logging verbosity can be controlled via the logLevel and logComponentVerbosity server parameters. Both of these parameters can be set either at startup or at runtime and expect integers. During runtime, it's possible for a non-numeric value to be passed into the setParameter command invocations for these parameters. Directly coercing these values into integers results in undefined behavior based on the processor architecture. For Graviton/Arm64 in particular, this can result in the log level being silently set to 0, which corresponds to info-level logging, rather than being rejected as an invalid value. We should explicitly check for NaN/non-numeric values and reject them before attempting type coercion to int. |
| Comments |
| Comment by Githook User [ 09/Nov/22 ] |
|
Author: {'name': 'Varun Ravichandran', 'email': 'varun.ravichandran@mongodb.com', 'username': 'varunravi98'}Message: |