On Wed, 21 Oct 2026 23:46:40 GMT, Xin Liu <[email protected]> wrote: >> Andrei Pangin has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains two commits: >> >> - Re-implemented native frames support using variable-size requests >> - 8392187: JFR: Use-after-free bug in CPU-time profiler can crash JVM > > 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.
Yeah, requiring `buildId` for _every_ binary is too strict. I'll relax the condition. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/32524#discussion_r4347842735
