clang Memory sanitizer (msan) and OpenJDK

[Baesken, Matthias]

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.bursie at oracle.com>
Sent: Thursday, 19 June 2025 17:07
To: Baesken, Matthias <matthias.baesken at sap.com>; build-dev at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250620/39cbb468/attachment.htm>