On Tue, 29 Sep 2026 10:38:42 GMT, Andrei Pangin <[email protected]> wrote:
>> This PR adds a new JFR frame type - for native (non-Java) frames. >> Native stack walking can be enabled with a new `FlightRecorderOption`. >> Only `jdk.CPUTimeSample` event can have native frames for now, but this can >> be extended to other events in the future. >> >> More details in https://bugs.openjdk.org/browse/JDK-8373791 >> >> Existing JFR tests pass. >> Added a new jtreg test that verifies sanity of collected native frames. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Andrei Pangin has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains two additional > commits since the last revision: > > - Re-implemented native frames support using variable-size requests > - 8392187: JFR: Use-after-free bug in CPU-time profiler can crash JVM src/hotspot/share/jfr/recorder/stacktrace/jfrNativeFunctionRepository.cpp line 164: > 162: const char* desc = name + align_up(nhdr->n_namesz, 4); > 163: pos = desc + align_up(nhdr->n_descsz, 4); > 164: if (pos > end) { I think it's fine that we assume the alignment is always 4. I check libjvm.so linked by gcc and clang. it's always 4 for.note.gnu.build-id. but there's a corner case that n_descsz is not multiple of 4. Let's say --build_id=0x123456, so descsz=3. it will round up to 4 at line 163. If `.note.gnu.build-id` happens to be the last section, this code will exit early at 165 because pos + 4 > end. We miss the valid build_id. We somehow need to execute 168-177 first before bumping pos. here is the similar logic in santizer-common. https://github.com/llvm/llvm-project/blob/a808f8ea7fdc61ead417bfe55e8ef5f728776aeb/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp#L742-L766 test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleNativeStack.java line 162: > 160: Asserts.assertNotEquals(library.getLong("baseAddress"), 0L, > "Library must have a base address"); > 161: String buildId = library.getString("buildId"); > 162: Asserts.assertNotNull(buildId, "Library must have a build > id"); Even though we restrict this jtreg test only on linux, can we safely assume build-id exists in native libraries? parse_build_id() relies on linker correctly emits ".note.gnu.build-id" section. This is true for GNU's toolchain. It's optional for llvm's toolchain. It's only default if you build it with a cmake flag: https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/Linux.cpp#L324 Actually, I can't even find -Wl,--build-id= for openjdk's clang configure. https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-ldflags.m4#L69 Let alone third-party libraries. JVM may load a solib that strip PT_NOTE sections. I know this test doesn't test any native library out of openjdk. I am just saying external native libraries are even more complex. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32524#discussion_r4343216679 PR Review Comment: https://git.openjdk.org/jdk/pull/32524#discussion_r4343136560
