clang Memory sanitizer (msan) and OpenJDK

Baesken, Matthias matthias.baesken at sap.com
Tue Apr 29 07:11:57 UTC 2025


  *   I thought I recognized this issue, and started searching the mail archive. Seems the same question was asked last year by ... you. :-)
Yeah I looked into msan some time ago and wanted to look into it again  now .


  *   I don't understand how the msan internal functions are supposed to work, if there is no library to link to. Are they added by the compiler?

I think so !  When I build a simple (working) example with msan   (clang++ -fsanitize=memory    in complie and link step, no libs added), I get a LOT of msan symbols in the resulting binary  :

nm msan_umr  | grep _msan  | more
00000000000221a0 t _GLOBAL__sub_I_msan_chained_origin_depot.cpp
0000000000057520 T __msan_allocated_memory
000000000004c5c0 T __msan_chain_origin
000000000004c2b0 T __msan_check_mem_is_initialized
0000000000093200 T __msan_clear_and_unpoison
000000000004c020 T __msan_clear_on_return
0000000000057600 T __msan_copy_shadow
000000000004cb50 W __msan_default_options
000000000004c150 T __msan_dump_shadow
000000000004ca60 T __msan_finish_switch_fiber
000000000004c3c0 T __msan_get_origin
000000000004ade0 T __msan_get_track_origins
000000000004c710 T __msan_get_umr_origin
   ....

  *   Maybe you can try patching out -fvisibility=hidden from the compile command line to see if that makes any difference.


Sounds like a good idea to start with, I will try this!   Seems the visibility stuff plays a role here.

Best regards, Matthias


From: Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>
Sent: Monday, 28 April 2025 22:06
To: Baesken, Matthias <matthias.baesken at sap.com>; build-dev at openjdk.org
Subject: Re: clang Memory sanitizer (msan) and OpenJDK


I thought I recognized this issue, and started searching the mail archive. Seems the same question was asked last year by ... you. :-)

https://mail.openjdk.org/pipermail/build-dev/2024-August/046011.html

I guess nobody still has a simple answer to give you. I don't understand how the msan internal functions are supposed to work, if there is no library to link to. Are they added by the compiler?

Maybe you can try patching out -fvisibility=hidden from the compile command line to see if that makes any difference.

/Magnus
On 2025-04-25 16:28, Baesken, Matthias wrote:
Hi,  Memory sanitizer
https://clang.llvm.org/docs/MemorySanitizer.html

is supported with the clang toolchain  (e.g. on Linux) ;  “MemorySanitizer is a detector of uninitialized memory use”  .

For small examples it is rather easy to use,   you just compile and link   with   -fsanitize=memory      (and for better results maybe additionally  -fno-omit-frame-pointer )   .

So I gave it a try with OpenJDK too and added   -fsanitize=memory      to the  C/CXX and LD flags  (--with-extra-cflags=-fsanitize=memory --with-extra-cxxflags=-fsanitize=memory --with-extra-ldflags=-fsanitize=memory ).
As far as compiling single  compilation units this seems to be okay .
But when it comes to executing the new generated binaries in the build process  we unfortunately  get  lookup errors / undefined symbols   :

/builddir/jdk/bin/javac: symbol lookup error:  /builddir/jdk/bin/../lib/libjli.so: undefined symbol: __msan_param_tls


Is there something special in our OpenJDK  build that causes trouble here ?


Here I found an somewhat similar looking issue :
https://groups.google.com/g/memory-sanitizer/c/xV3OZZCiL9A

where re-exporting symbols is mentioned -  is this maybe something that hits us in OpenJDK too ?


For address sanitizer, we set  -shared-libasan in the OpenJDK :

https://github.com/openjdk/jdk/blob/5c067232bf21aaca2b7addd2a862e15a8696ffb8/make/autoconf/jdk-options.m4#L449
ASAN_LDFLAGS="$ASAN_LDFLAGS -shared-libasan"

But I could not find something similar for msan .


(btw. I use clang 15.0.7 on SUSE Linux x86_64 in case this matters)


Best regards, Matthias







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20250429/4b382f19/attachment-0001.htm>


More information about the build-dev mailing list