RFR: 8346881: [ubsan] logSelection.cpp:154:24 / logSelectionList.cpp:72:94 : runtime error: applying non-zero offset 1 to null pointer

[Matthias Baesken]

On Thu, 2 Jan 2025 13:15:17 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> When running jtreg tests on macOS aarch64 with ubsanized binaries, the following error is reported :
>> 
>> 
>> jdk/src/hotspot/share/logging/logSelection.cpp:154:24: runtime error: applying non-zero offset 1 to null pointer
>> UndefinedBehaviorSanitizer:DEADLYSIGNAL
>> UndefinedBehaviorSanitizer: nested bug in the same thread, aborting.
>> 
>> 
>> (XCode 13.1 was used)
>> 
>> This can be seen e.g. in these jdk jtreg tests :
>> jdk/internal/misc/CDS/ArchivedEnumTest.java
>> jdk/jfr/event/gc/collection/TestGCGarbageCollectionEvent.java
>> jdk/jfr/startupargs/TestDumpOnExit.java
>> 
>> There is another issue observed here (also when running on macOS aarch64) , seems this happens in the for loop when incrementing comma_pos
>> " for (char *comma_pos = copy, *cur = copy; success && comma_pos != nullptr; cur = comma_pos + 1) { ..."
>> 
>> 
>> src/hotspot/share/logging/logSelectionList.cpp:72:94: runtime error: applying non-zero offset 1 to null pointer
>> UndefinedBehaviorSanitizer:DEADLYSIGNAL
>> UndefinedBehaviorSanitizer: nested bug in the same thread, aborting.
>
> src/hotspot/share/logging/logSelectionList.cpp line 96:
> 
>> 94:     if (comma_pos == nullptr) {
>> 95:       break;
>> 96:     }
> 
> I think this check is not necessary here since it is checked in the for loop condition already - or am I overlooking something?

Unfortunately we still run into the issue , even with the existing loop condition.
check the flowchart of the for loop 
https://www.programiz.com/cpp-programming/for-loop
the update condition is done after the body ; then we run into the issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22903#discussion_r1900893913