On Mon, 10 Jun 2024 12:30:59 GMT, Matthias Baesken <mbaes...@openjdk.org> wrote:
> When running hs :tier1 tests or jdk/jfr tests, with ubsan enabled (configure > flag --enable-ubsan), in a lot of jfr related tests like > compiler/intrinsics/klass/CastNullCheckDroppingsTest.jtr > serviceability/jvmti/RedefineClasses/RedefineSharedClassJFR.jtr > this oob error can be seen : > > /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.inline.hpp:31:43: runtime > error: index 163 out of bounds for type 'jfrNativeEventSetting [162]' > #0 0x7f6b75a8634b in JfrEventSetting::setting(JfrEventId) > /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.inline.hpp:31 > #1 0x7f6b75a8634b in JfrEventSetting::set_stacktrace(long, bool) > /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.cpp:47 > > Looks like the array in generated code is too small. > With > `jfrNativeEventSetting bits[NUMBER_OF_EVENTS];` > and > > static const int NUMBER_OF_EVENTS = 162; > static const int NUMBER_OF_RESERVED_EVENTS = 2; > > > Access at index 163 cannot work. > But it looks like there is always enough memory after the array so we do not > crash and it was not noticed before. Good catch! But I am not sure the solution is correct, or not enough. On my machine (linux x64), I see 169 explicitly named events in `JfrNativeSettings::ev`. But then, `NUMBER_OF_EVENTS = 162;` and `NUMBER_OF_RESERVED_EVENTS = 2;` . => 164. So, the last 5 events are not covered by the `bits` array even with your change. So, there is a mismatch somewhere between `metadata.getEventsAndStructs()` (used to print out individual event data) and `metadata.eventCounter.count` (used to determine NUMBER_OF_EVENTS). ---- If you have figured this out, and fixed it, could you please let the generator add a STATIC_ASSERT( sizeof(JfrNativeSettings::ev) == sizeof(JfrNativeSettings::bits) ); to the header? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19628#issuecomment-2160739146
