On Wed, 27 Aug 2025 14:39:01 GMT, Matthias Baesken <mbaes...@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

Reply via email to