jmx-dev RFR: 8366092: [GCC static analyzer] UnixOperatingSystem.c warning: use of uninitialized value 'systemTicks' [v2]

[Kevin Walls]

On Wed, 27 Aug 2025 14:39:01 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> When using gcc static analyzer (-fanalyzer) with gcc 13.2 the following issue is reported :
>> 
>> /jdk/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c: In function 'get_jvmticks':
>> /jdk/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c:208:24: warning: use of uninitialized value 'systemTicks' [CWE-457] [-Wanalyzer-use-of-uninitialized-value]
>>   208 | pticks->usedKernel = systemTicks;
>> 
>> 
>> vsscanf usually/normally reads the systemTicks info from /proc file system. see
>> https://github.com/openjdk/jdk/blob/45726a1f8b8f76586037867a32b82f8ab9b96937/src/jdk.management/linux/native/libmanagement_ext/UnixOperatingSystem.c#L163
>> but we never check that the *exact* number of params is read with vsscanf :
>> n = vsscanf(tmp, fmt, args);
>> So potentially we could get a non complete info without systemTicks and the call would still succeed.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   init vars so that gcc static analyzer is happy too

Yes, seems we have two almost identical read_ticks functions, that's not ideal but hotspot and libmanagement both needed it... Maybe that can be deduplicated in future. 8-)


If we now return when read_ticks doesn't read and set both variables, then the "use of uninitialized value" warning becomes incorrect.

And with the !=2 check it becomes the same as the other usage, in src/hotspot/os/linux/os_perf_linux.cpp

 313 static OSReturn get_jvm_ticks(os::Linux::CPUPerfTicks* pticks) {
 314   uint64_t userTicks;
 315   uint64_t systemTicks;
...
 321   if (read_ticks("/proc/self/stat", &userTicks, &systemTicks) != 2) {
 322     return OS_ERR;
 323   }

...so does that other code have the same analyzer warning?

Ideally I expect we would not change the code just to keep a tool happy, if the warning is not really accurate.... (and presumably the warning might get more accurate in future)

-------------

PR Review: https://git.openjdk.org/jdk/pull/26962#pullrequestreview-3161078387