Hi Magnus, > I think there might be ways around that to tell the linker to actually keep > the symbols we need. If you want to pursue integrating msan into the JDK > build properly, we can explore that.
I am still a bit unsure about integrating the msan support , because with just the msan support in the m4+makefiles , but still msan-related runtime issues showing up in the build, It would not be very helpful for the developers. (on the other hand, ubsan in OpenJDK was some months ago also only supported in the m4+makefiles but needed ‘repair’ regarding source adjustments because issues already showed up in the build ) >>Seems msan is unhappy about the thread != nullptr in line 81 of >>jfrThreadLocal.cpp >I have no idea. Did you pursue this any further, or did you give up? I updated to a higher version of clang (17) and then the issue was gone ; but unfortunately there are more msan – related issues reported in Hotspot already in the build process . And different to ubsan/asan , for me the msan issues are harder to understand (but maybe I am just not used to the reports yet ) . Maybe , let’s see what comes out of this one https://bugs.openjdk.org/browse/JDK-8356285 . (sometimes the HS codebase seem to does things that are not liked by MSAN ; maybe the JDK native libs are easier to support for MSAN ) Best regards, Matthias From: Magnus Ihse Bursie <magnus.ihse.bur...@oracle.com> Sent: Thursday, 19 June 2025 17:07 To: Baesken, Matthias <matthias.baes...@sap.com>; build-dev@openjdk.org Subject: Re: clang Memory sanitizer (msan) and OpenJDK Hi Matthias, Getting back to this far too late... Sorry. On 2025-04-30 15:28, Baesken, Matthias wrote: I installed the llvm package to get the /usr/bin/llvm-symbolizer (this seems to be needed to get meaningful stacks) . Brought back the visibility=hidden settings, seems they do no harm to msan . However the removal of -Wl,--exclude-libs,ALL is needed. I think there might be ways around that to tell the linker to actually keep the symbols we need. If you want to pursue integrating msan into the JDK build properly, we can explore that. If so, we should also check for the presence of llvm-symbolizer in configure and warn if it is missing (though I guess the real question is if it is present at runtime...). Seems msan is unhappy about the thread != nullptr in line 81 of jfrThreadLocal.cpp Thread* thread = Thread::current_or_null(); _parent_trace_id = thread != nullptr ? jvm_thread_id(thread) : (traceid)0; Not sure why this is reported as uninitialized ? I have no idea. Did you pursue this any further, or did you give up? /Magnus
