RFR: 8283059: Uninitialized warning in check_code.c with GCC 11.2 [v2]

Mikael Vidstedt mikael at openjdk.java.net
Thu Mar 17 20:41:37 UTC 2022


On Thu, 17 Mar 2022 20:36:31 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> Background, from JBS:
>> 
>> src/java.base/share/native/libverify/check_code.c: In function 'read_all_code': 
>> src/java.base/share/native/libverify/check_code.c:942:5: error: 'lengths' may be used uninitialized [-Werror=maybe-uninitialized] 
>>   942 | check_and_push(context, lengths, VM_MALLOC_BLK); 
>>       | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
>> src/java.base/share/native/libverify/check_code.c:4145:13: note: by argument 2 of type 'const void *' to 'check_and_push' declared here 
>>  4145 | static void check_and_push(context_type *context, const void *ptr, int kind) 
>>       | ^~~~~~~~~~~~~~ 
>> 
>> 
>> Because the second argument of check_and_push is "const void*" GCC assumes that the malloc:ed data, which has not yet been initialized, will not be/can not be modified later which in turn suggests it may be used without ever being initialized. 
>> 
>> The same general issue was addressed in [JDK-8266168](https://bugs.openjdk.java.net/browse/JDK-8266168), presumably for GCC 11.1.
>> 
>> 
>> Details:
>> 
>> Instead of sprinkling more calloc calls around or using pragmas/gcc attributes I chose to change the check_and_push function to take a (non-const) void* argument, and provide a new wrapper function `check_and_push_const` which handles the const argument case. For the (non-const) VM_MALLOC_BKP that means the pointer never needs to go through a const conversion.
>> 
>> To avoid having multiple ways of solving the same problem I also chose to revert the change made in JDK-8266168, reverting the calloc back to a malloc call.
>> 
>> Testing:
>> 
>> tier1 + builds-tier{2,3,4,5}
>
> Mikael Vidstedt has updated the pull request incrementally with 50 additional commits since the last revision:
> 
>  - Spell out check_and_push_malloc_block
>  - Fix code
>  - 8282773: Refactor parsing of integer VM options
>    
>    Reviewed-by: dholmes, kbarrett
>  - 8283274: Improve @jvms usage in java.base
>    
>    Reviewed-by: iris
>  - 8283188: Build time regression caused by JDK-8278917
>    
>    Reviewed-by: kbarrett, tschatzl
>  - 8283320: Error message for Windows libraries always points to --with-msvcr-dll no matter the actual file name
>    
>    Reviewed-by: erikj, ihse
>  - 8283056: show abstract machine code in hs-err for all VM crashes
>    
>    Reviewed-by: thartmann, dholmes
>  - 8282727: Parallel: Remove PSPromotionManager::_totally_drain
>    
>    Reviewed-by: tschatzl, kbarrett
>  - 8281146: Replace StringCoding.hasNegatives with countPositives
>    
>    Co-authored-by: Lutz Schmidt <lucy at openjdk.org>
>    Co-authored-by: Martin Doerr <mdoerr at openjdk.org>
>    Reviewed-by: kvn, lucy, rriggs
>  - 8282602: Refactor awt classes javadoc to use @throws instead of @exception
>    
>    Reviewed-by: aivanov, prr
>  - ... and 40 more: https://git.openjdk.java.net/jdk/compare/baf72097...eb04d78a

Um.. I think I managed to mess up this PR when I brought in latest master *and* tried it both with the current and new version of gcc. Sorry about that. I'll withdraw this one and open a new PR

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

PR: https://git.openjdk.java.net/jdk/pull/7794


More information about the core-libs-dev mailing list