On Thu, 17 Mar 2022 06:59:01 GMT, David Holmes <dhol...@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} > > src/java.base/share/native/libverify/check_code.c line 4168: > >> 4166: } >> 4167: >> 4168: static void check_and_push_const(context_type *context, const void >> *ptr, int kind) { > > IIUC the only `const` cases all pass a `const char*` so perhaps we can make > that explicit in the signature? I confess I can't figure out how the passed > in memory eventually gets used and it seems bizarre that it could be a > freshly malloc'd block or an existing string. David - The check_and_push idiom checks if ptr is null, doing the out of memory handling if so. Otherwise, add ptr to a collection for later release. The kind determines how the release is done, either JVM_ReleaseUTF or free. ------------- PR: https://git.openjdk.java.net/jdk/pull/7794
