Re: [cfe-users] Segmentation fault with memory sanitizer and OpenMPI's mpirun
This is caused by missing -lutil. FTR, http://llvm.org/viewvc/llvm-project?rev=245619&view=rev On Mon, Nov 23, 2015 at 7:33 AM, Schlottke-Lakemper, Michael via cfe-users wrote: > Hi folks, > > When running “mpirun” of an msan-instrumented installation of OpenMPI, I get > the following error: > > $> mpirun -n 1 hostname > [aia308:48324] *** Process received signal *** > [aia308:48324] Signal: Segmentation fault (11) > [aia308:48324] Signal code: Address not mapped (1) > [aia308:48324] Failing at address: (nil) > [aia308:48324] [ 0] > /pds/opt/openmpi-1.8.7-clang-msan/lib64/libopen-pal.so.6(+0x123ca1)[0x7f9e21c90ca1] > [aia308:48324] [ 1] mpirun[0x42b602] > [aia308:48324] [ 2] /lib64/libpthread.so.0(+0xf890)[0x7f9e21250890] > [aia308:48324] *** End of error message *** > Segmentation fault > > Running it through gdb and printing the stacktrace, I get the following > additional information: > $> gdb -ex r --args mpirun -n 1 hostname > #0 0x in ?? () > #1 0x0042bd5b in __interceptor_openpty () at > /pds/opt/install/llvm/llvm-20151121-r253770-src/projects/compiler-rt/lib/msan/msan_interceptors.cc:1355 > #2 0x77705a7c in opal_openpty (amaster=0x7fffacf8, > aslave=0x7fffacfc, name=0x0, termp=0x0, winp=0x0) at > ../../../openmpi-1.8.7/opal/util/opal_pty.c:116 > #3 0x77b31e9a in orte_iof_base_setup_prefork (opts=0x7ffface8) > at ../../../../openmpi-1.8.7/orte/mca/iof/base/iof_base_setup.c:89 > #4 0x7fffefea465a in odls_default_fork_local_proc > (context=0x7240bb80, child=0x7240b880, environ_copy=0x7341ec00, > jobdat=0x72209d80) at > ../../../../../openmpi-1.8.7/orte/mca/odls/default/odls_default_module.c:860 > #5 0x77b3cfb8 in orte_odls_base_default_launch_local (fd=-1, sd=4, > cbdata=0x7062da80) at > ../../../../openmpi-1.8.7/orte/mca/odls/base/odls_base_default_fns.c:1544 > #6 0x777459d7 in event_process_active_single_queue > (base=0x72a0fc80, activeq=0x7100bdc0) at > ../../../../../../openmpi-1.8.7/opal/mca/event/libevent2021/libevent/event.c:1367 > #7 0x7773bb92 in event_process_active (base=0x72a0fc80) at > ../../../../../../openmpi-1.8.7/opal/mca/event/libevent2021/libevent/event.c:1437 > #8 0x77738fd7 in opal_libevent2021_event_base_loop > (base=0x72a0fc80, flags=1) at > ../../../../../../openmpi-1.8.7/opal/mca/event/libevent2021/libevent/event.c:1647 > #9 0x0048f651 in orterun (argc=4, argv=0x7fffcea8) at > ../../../../openmpi-1.8.7/orte/tools/orterun/orterun.c:1133 > #10 0x0048b20c in main (argc=4, argv=0x7fffcea8) at > ../../../../openmpi-1.8.7/orte/tools/orterun/main.c:13 > > I suspect that has something to do with using some non-msan-instrumented > system libraries, but how can I find out which library is the problem and > what to do to fix it? Any ideas? > > Regards, > > Michael > > P.S.: I compiled OpenMPI with the following configure command (the wildcard > blacklist was necessary because OpenMPI just has too many issues with msan…): > > printf "fun:*\n" > blacklist.txt && \ > CC=clang CXX=clang++ \ > CFLAGS="-g -fsanitize=memory -fno-omit-frame-pointer > -fsanitize-memory-track-origins -fsanitize-blacklist=`pwd`/blacklist.txt" \ > CXXFLAGS="-g -fsanitize=memory -fno-omit-frame-pointer > -fsanitize-memory-track-origins -fsanitize-blacklist=`pwd`/blacklist.txt" \ > ../openmpi-1.8.7/configure --prefix=/pds/opt/openmpi-1.8.7-clang-msan > --disable-mpi-fortran > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Errors when trying to use libcxx/libcxxabi with memory sanitizer
On Mon, Nov 23, 2015 at 12:59 AM, Schlottke-Lakemper, Michael via cfe-users wrote: > Hi folks, > > I'm trying to set up our cluster tool chain to support clang’s memory > sanitizer for our multiphysics simulation program, but I can’t get it to > work :-/ > > I started with a regularly compiled clang installation (with libcxx, > libcxxabi, and libomp built in-tree). With this, I compiled all necessary > third-party libraries with “-O1 -fsanitize=memory” (OpenMPI, FFTW, Parallel > netCDF). Then, I compiled the libcxx/libcxxabi libraries with msan-support > by checking out the llvm source and the libcxx/libcxxabi repos into the > llvm/projects/ directory. I configured them with LLVM_USE_SANITIZER=Memory > and put the msan-instrumented libraries in the LD_LIBRARY_PATH. > > Finally, I tried to compile our tool, ZFS, with the memory sanitizer enabled > and linked against the msan-compiled third-party libraries as well as the > msan-instrumented libcxx/libcxxabi libraries (by putting them in the > LD_LIBRARY_PATH). However, here I failed: either at configure time or at > compile time (after doing some LD_LIBRARY_PATH trickery), clang exits with > the following error: > > /pds/opt/llvm-20151121-r253770/bin/clang++: symbol lookup error: > /pds/opt/libcxx-msan-20151121-r253770/lib/libc++abi.so.1: undefined symbol: > __msan_va_arg_overflow_size_tls > > Any suggestions as to what I am doing wrong? Should I put the > msan-instrumented libcxx in the LD_LIBRARY_PATH after compilation only? Yes, probably. In this case your compiler, which is not built with MSan, picked up an instrumented libc++abi. Sometimes it is convenient to set RPATH on all msan libraries/executables and avoid LD_LIBRARY_PATH. > > Thanks a lot in advance > > Michael > > > -- > Michael Schlottke-Lakemper > > Chair of Fluid Mechanics and Institute of Aerodynamics > RWTH Aachen University > Wüllnerstraße 5a > 52062 Aachen > Germany > > Phone: +49 (241) 80 95188 > Fax: +49 (241) 80 92257 > Mail: m.schlottke-lakem...@aia.rwth-aachen.de > Web: http://www.aia.rwth-aachen.de > > > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users > ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Errors when trying to use libcxx/libcxxabi with memory sanitizer
Yes. Effectively you need two environments - one with msan-instrumented libraries, and one without. Compilation should happen in the latter (unless you want to instrument the compiler which is not very productive), and resulting binaries should be run in the former. On Mon, Nov 23, 2015 at 10:50 AM, Schlottke-Lakemper, Michael wrote: > >> On 23 Nov 2015, at 18:11 , Evgenii Stepanov >> wrote: >> >> On Mon, Nov 23, 2015 at 12:59 AM, Schlottke-Lakemper, Michael via >> cfe-users wrote: >>> Hi folks, >>> >>> I'm trying to set up our cluster tool chain to support clang’s memory >>> sanitizer for our multiphysics simulation program, but I can’t get it to >>> work :-/ >>> >>> I started with a regularly compiled clang installation (with libcxx, >>> libcxxabi, and libomp built in-tree). With this, I compiled all necessary >>> third-party libraries with “-O1 -fsanitize=memory” (OpenMPI, FFTW, Parallel >>> netCDF). Then, I compiled the libcxx/libcxxabi libraries with msan-support >>> by checking out the llvm source and the libcxx/libcxxabi repos into the >>> llvm/projects/ directory. I configured them with LLVM_USE_SANITIZER=Memory >>> and put the msan-instrumented libraries in the LD_LIBRARY_PATH. >>> >>> Finally, I tried to compile our tool, ZFS, with the memory sanitizer enabled >>> and linked against the msan-compiled third-party libraries as well as the >>> msan-instrumented libcxx/libcxxabi libraries (by putting them in the >>> LD_LIBRARY_PATH). However, here I failed: either at configure time or at >>> compile time (after doing some LD_LIBRARY_PATH trickery), clang exits with >>> the following error: >>> >>> /pds/opt/llvm-20151121-r253770/bin/clang++: symbol lookup error: >>> /pds/opt/libcxx-msan-20151121-r253770/lib/libc++abi.so.1: undefined symbol: >>> __msan_va_arg_overflow_size_tls >>> >>> Any suggestions as to what I am doing wrong? Should I put the >>> msan-instrumented libcxx in the LD_LIBRARY_PATH after compilation only? >> >> Yes, probably. In this case your compiler, which is not built with >> MSan, picked up an instrumented libc++abi. >> Sometimes it is convenient to set RPATH on all msan >> libraries/executables and avoid LD_LIBRARY_PATH. > > Thanks for your answer. Unfortunately, I cannot avoid LD_LIBRARY_PATH as it > includes our cluster-wide LLVM lib dir by default on all our hosts. Thus > setting RPATH at compile/link time will have no effect as there is no way to > make it overrule LD_LIBRARY_PATH afaik. Instrumenting all of Clang with MSan > seems a bit overkill to me (and does not solve the RPATH/LD_LIBRARY_PATH > issue at runtime anyways). I guess I’ll just have to live with manually > changing the LD_LIBRARY_PATH after compilation then. > > Michael ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Segmentation fault with memory sanitizer and OpenMPI's mpirun
I think so. What probably happens here is MSan confuses the configure script into thinking that openpty is available without -lutil, but what's actually available is just a stub that tries calling the real openpty and fails, unless libutil is linked. On Mon, Nov 23, 2015 at 10:41 AM, Schlottke-Lakemper, Michael wrote: > Hi Evgenii, > > Just to clarify: you mean I should re-compile OpenMPI and add “-lutil” to > LDFLAGS at configure time? > > Yours > > Michael > >> On 23 Nov 2015, at 18:07 , Evgenii Stepanov >> wrote: >> >> This is caused by missing -lutil. >> FTR, http://llvm.org/viewvc/llvm-project?rev=245619&view=rev >> >> On Mon, Nov 23, 2015 at 7:33 AM, Schlottke-Lakemper, Michael via >> cfe-users wrote: >>> Hi folks, >>> >>> When running “mpirun” of an msan-instrumented installation of OpenMPI, I >>> get the following error: >>> >>> $> mpirun -n 1 hostname >>> [aia308:48324] *** Process received signal *** >>> [aia308:48324] Signal: Segmentation fault (11) >>> [aia308:48324] Signal code: Address not mapped (1) >>> [aia308:48324] Failing at address: (nil) >>> [aia308:48324] [ 0] >>> /pds/opt/openmpi-1.8.7-clang-msan/lib64/libopen-pal.so.6(+0x123ca1)[0x7f9e21c90ca1] >>> [aia308:48324] [ 1] mpirun[0x42b602] >>> [aia308:48324] [ 2] /lib64/libpthread.so.0(+0xf890)[0x7f9e21250890] >>> [aia308:48324] *** End of error message *** >>> Segmentation fault >>> >>> Running it through gdb and printing the stacktrace, I get the following >>> additional information: >>> $> gdb -ex r --args mpirun -n 1 hostname >>> #0 0x in ?? () >>> #1 0x0042bd5b in __interceptor_openpty () at >>> /pds/opt/install/llvm/llvm-20151121-r253770-src/projects/compiler-rt/lib/msan/msan_interceptors.cc:1355 >>> #2 0x77705a7c in opal_openpty (amaster=0x7fffacf8, >>> aslave=0x7fffacfc, name=0x0, termp=0x0, winp=0x0) at >>> ../../../openmpi-1.8.7/opal/util/opal_pty.c:116 >>> #3 0x77b31e9a in orte_iof_base_setup_prefork (opts=0x7ffface8) >>> at ../../../../openmpi-1.8.7/orte/mca/iof/base/iof_base_setup.c:89 >>> #4 0x7fffefea465a in odls_default_fork_local_proc >>> (context=0x7240bb80, child=0x7240b880, environ_copy=0x7341ec00, >>> jobdat=0x72209d80) at >>> ../../../../../openmpi-1.8.7/orte/mca/odls/default/odls_default_module.c:860 >>> #5 0x77b3cfb8 in orte_odls_base_default_launch_local (fd=-1, sd=4, >>> cbdata=0x7062da80) at >>> ../../../../openmpi-1.8.7/orte/mca/odls/base/odls_base_default_fns.c:1544 >>> #6 0x777459d7 in event_process_active_single_queue >>> (base=0x72a0fc80, activeq=0x7100bdc0) at >>> ../../../../../../openmpi-1.8.7/opal/mca/event/libevent2021/libevent/event.c:1367 >>> #7 0x7773bb92 in event_process_active (base=0x72a0fc80) at >>> ../../../../../../openmpi-1.8.7/opal/mca/event/libevent2021/libevent/event.c:1437 >>> #8 0x77738fd7 in opal_libevent2021_event_base_loop >>> (base=0x72a0fc80, flags=1) at >>> ../../../../../../openmpi-1.8.7/opal/mca/event/libevent2021/libevent/event.c:1647 >>> #9 0x0048f651 in orterun (argc=4, argv=0x7fffcea8) at >>> ../../../../openmpi-1.8.7/orte/tools/orterun/orterun.c:1133 >>> #10 0x0048b20c in main (argc=4, argv=0x7fffcea8) at >>> ../../../../openmpi-1.8.7/orte/tools/orterun/main.c:13 >>> >>> I suspect that has something to do with using some non-msan-instrumented >>> system libraries, but how can I find out which library is the problem and >>> what to do to fix it? Any ideas? >>> >>> Regards, >>> >>> Michael >>> >>> P.S.: I compiled OpenMPI with the following configure command (the wildcard >>> blacklist was necessary because OpenMPI just has too many issues with >>> msan…): >>> >>> printf "fun:*\n" > blacklist.txt && \ >>> CC=clang CXX=clang++ \ >>> CFLAGS="-g -fsanitize=memory -fno-omit-frame-pointer >>> -fsanitize-memory-track-origins -fsanitize-blacklist=`pwd`/blacklist.txt" \ >>> CXXFLAGS="-g -fsanitize=memory -fno-omit-frame-pointer >>> -fsanitize-memory-track-origins -fsanitize-blacklist=`pwd`/blacklist.txt" \ >>> ../openmpi-1.8.7/configure --prefix=/pds/opt/openmpi-1.8.7-clang-msan >>> --disable-mpi-fortran >>> ___ >>> cfe-users mailing list >>> cfe-users@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users > ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Errors when trying to use libcxx/libcxxabi with memory sanitizer
It works in general. On Mon, Nov 23, 2015 at 11:13 AM, Schlottke-Lakemper, Michael wrote: > >> On 23 Nov 2015, at 20:01 , Evgenii Stepanov >> wrote: >> >> Yes. Effectively you need two environments - one with >> msan-instrumented libraries, and one without. Compilation should >> happen in the latter (unless you want to instrument the compiler which >> is not very productive), and resulting binaries should be run in the >> former. >> > > Ah, thanks a lot. Just to be sure: is it generally OK to compile & link in an > environment where ld would e.g. pick up an uninstrumented version of the > OpenMPI libraries as long as the correct, instrumented OpenMPI library is in > LD_LIBRARY_PATH at runtime? > > Sorry for having to ask again > > Michael > > >> On Mon, Nov 23, 2015 at 10:50 AM, Schlottke-Lakemper, Michael >> wrote: >>> On 23 Nov 2015, at 18:11 , Evgenii Stepanov wrote: On Mon, Nov 23, 2015 at 12:59 AM, Schlottke-Lakemper, Michael via cfe-users wrote: > Hi folks, > > I'm trying to set up our cluster tool chain to support clang’s memory > sanitizer for our multiphysics simulation program, but I can’t get it to > work :-/ > > I started with a regularly compiled clang installation (with libcxx, > libcxxabi, and libomp built in-tree). With this, I compiled all necessary > third-party libraries with “-O1 -fsanitize=memory” (OpenMPI, FFTW, > Parallel > netCDF). Then, I compiled the libcxx/libcxxabi libraries with msan-support > by checking out the llvm source and the libcxx/libcxxabi repos into the > llvm/projects/ directory. I configured them with LLVM_USE_SANITIZER=Memory > and put the msan-instrumented libraries in the LD_LIBRARY_PATH. > > Finally, I tried to compile our tool, ZFS, with the memory sanitizer > enabled > and linked against the msan-compiled third-party libraries as well as the > msan-instrumented libcxx/libcxxabi libraries (by putting them in the > LD_LIBRARY_PATH). However, here I failed: either at configure time or at > compile time (after doing some LD_LIBRARY_PATH trickery), clang exits with > the following error: > > /pds/opt/llvm-20151121-r253770/bin/clang++: symbol lookup error: > /pds/opt/libcxx-msan-20151121-r253770/lib/libc++abi.so.1: undefined > symbol: > __msan_va_arg_overflow_size_tls > > Any suggestions as to what I am doing wrong? Should I put the > msan-instrumented libcxx in the LD_LIBRARY_PATH after compilation only? Yes, probably. In this case your compiler, which is not built with MSan, picked up an instrumented libc++abi. Sometimes it is convenient to set RPATH on all msan libraries/executables and avoid LD_LIBRARY_PATH. >>> >>> Thanks for your answer. Unfortunately, I cannot avoid LD_LIBRARY_PATH as it >>> includes our cluster-wide LLVM lib dir by default on all our hosts. Thus >>> setting RPATH at compile/link time will have no effect as there is no way >>> to make it overrule LD_LIBRARY_PATH afaik. Instrumenting all of Clang with >>> MSan seems a bit overkill to me (and does not solve the >>> RPATH/LD_LIBRARY_PATH issue at runtime anyways). I guess I’ll just have to >>> live with manually changing the LD_LIBRARY_PATH after compilation then. >>> >>> Michael > ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] Code locations from the Memory Sanitizer
For MSan, you'll need MSAN_SYMBOLIZER_PATH. Or just add to PATH, it would work for all sanitizers. On Fri, Apr 28, 2017 at 3:30 AM, Rainer Gerhards via cfe-users wrote: > 2017-04-28 12:25 GMT+02:00 Erik de Castro Lopo via cfe-users > : >> Hi all, >> >> I've tried Clang versions 3.6, 3.9 and 5.0 (all installed from Debian >> packages on a Debian x86_64 machine), but I still can't get Memory >> Sanitizer to give me the error file and line number locations. >> >> The project is >> >>http://github.com/erikd/libsndfile >> >> and I'm configuring/building it with eg: >> >> CC=clang-5.0 >> CXX=clang++-5.0 >> CFLAGS="-fsanitize=memory -fno-omit-frame-pointer -g >> -Wno-expansion-to-defined" >> CXXFLAGS=$CFLAGS >> ./configure --enable-werror --disable-shared >> make clean all check >> >> and I get: >> >> broadcast_test : broadcast.rf64 .. >> Uninitialized bytes in __interceptor_write at offset 36 inside >> [0x7100, 104) >> ==15113==WARNING: MemorySanitizer: use-of-uninitialized-value >> #0 0x67802e (/home/erik/Git/libsndfile/tests/command_test+0x67802e) >> #1 0x600404 (/home/erik/Git/libsndfile/tests/command_test+0x600404) >> #2 0x5f72f6 (/home/erik/Git/libsndfile/tests/command_test+0x5f72f6) >> #3 0x4be48b (/home/erik/Git/libsndfile/tests/command_test+0x4be48b) >> #4 0x4c06d6 (/home/erik/Git/libsndfile/tests/command_test+0x4c06d6) >> #5 0x4b1cfc (/home/erik/Git/libsndfile/tests/command_test+0x4b1cfc) >> #6 0x4a10c6 (/home/erik/Git/libsndfile/tests/command_test+0x4a10c6) >> #7 0x495dbf (/home/erik/Git/libsndfile/tests/command_test+0x495dbf) >> #8 0x7f3f37cf22b0 (/lib/x86_64-linux-gnu/libc.so.6+0x202b0) >> #9 0x41ef79 (/home/erik/Git/libsndfile/tests/command_test+0x41ef79) >> >> I expected to get file and line number position as shown in the >> documentation. >> >> Clues? > > I often need to set the ASAN_SYMBOLIZER_PATH: > > https://clang.llvm.org/docs/AddressSanitizer.html#id4 > > It often tends to be wrong by package default... > > HTH > Rainer > >> >> Erik >> -- >> -- >> Erik de Castro Lopo >> http://www.mega-nerd.com/ >> ___ >> cfe-users mailing list >> cfe-users@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] MSAN blacklist
This is a report from an interceptor, it is not affected by blacklist, unfortunately. You could try MSAN_OPTIONS=intercept_strlen=0, but it is likely that something else will pop up instead. Try figuring out what is the actual reason for the report, i.e. what code is supposed to initialize this memory. Is it some other library that can be built with MSan? A better place for such questions is https://github.com/google/sanitizers/issues On Mon, Jan 29, 2018 at 5:59 AM, Bernd Schubert via cfe-users wrote: > Hello, > > I would like to blacklist some warnings, but everything I tried > so far is ignored. > > # cat msan-blacklist.txt > fun:*interceptor_strlen* > fun:*foreach_dirinpath* > fun:foreach_dirinpath > fun:*interceptor_strrchr* > fun:*try_dlopen* > src:*/ltdl.c > src:ltdl.c > > So I tried to blacklist all kind of combinations of the failing > functions and also of the related file - without success. It always > fails with the same issue. > > > > Uninitialized bytes in __interceptor_strlen at offset 0 inside > [0x70335370, 45) > ==3968020==WARNING: MemorySanitizer: use-of-uninitialized-value > #0 0x7f0f587fa099 in foreach_dirinpath > /home/bschubert/src/cci/gerrit/src/libltdl/ltdl.c:699:18 > [...] > > Uninitialized value was created by a heap allocation > #0 0x453ebd in __interceptor_malloc (/tmp/ime-server-bernd.0+0x453ebd) > #1 0x7f0f568c0f7e in __argz_create_sep (/usr/lib64/libc.so.6+0x90f7e) > #2 0x7f0f585f7775 in _dl_fixup (/lib64/ld-linux-x86-64.so.2+0xe775) > > SUMMARY: MemorySanitizer: use-of-uninitialized-value > /home/bschubert/src/cci/gerrit/src/libltdl/ltdl.c:699:18 in > foreach_dirinpath > Exiting > > > libcci and the main project I'm working on is compiled liked this > > libtool: compile: /opt/llvm-5.0.1/bin/clang -DHAVE_CONFIG_H -I. > -DLTDLOPEN=libltdlc "-DLT_CONFIG_H=" -DLTDL -I. -I. -Ilibltdl > -I./libltdl -I./libltdl -ggdb3 -O2 -fsanitize=memory > -fsanitize-memory-track-origins -fsanitize-memory-use-after-dtor > -fsanitize-blacklist=msan-blacklist.txt -MT libltdlc_la-lt_dlloader.lo > -MD -MP -MF .deps/libltdlc_la-lt_dlloader.Tpo -c lt_dlloader.c -fPIC > -DPIC -o .libs/libltdlc_la-lt_dlloader.o > > > Any ideas? > > > Thanks, > Bernd > ___ > cfe-users mailing list > cfe-users@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
Re: [cfe-users] MSAN blacklist
Interceptors are defined here: https://github.com/llvm-project/llvm-project-20170507/blob/master/compiler-rt/lib/sanitizer_common/sanitizer_common_interceptors.inc On Tue, Jan 30, 2018 at 4:17 PM, Bernd Schubert wrote: > Thanks for your help Evgenii! > > This is actually another glibc feature and so internal to glibc (in my > personal opinion, just bloat, but probably not easy to remove nowadays). > > This is basically the function > https://code.woboq.org/userspace/glibc/string/argz-ctsep.c.html > > So the argz feature (no idea why this has to be in main glibc) > https://www.gnu.org/software/libc/manual/html_node/Argz-Functions.html > > > It got a bit late (I shouldn't have tried to compile glibc with llvm), I > will try to overload/LD_PRELOAD argz_create_sep() tomorrow and memset > the allocated memory. > Unfortunately I don't have much control over the user of this function > this is gnu-libtool / libltdl, which is just copied/linked into the > project. > > I will also open an issue on github, as this is glibc, so these argz > functions probably should be intersepted by llvm. > I'm not familiar with llvm code at all. Is it > llvm::inferLibFuncAttributes(), which defines intercepted functions? > > > Thanks, > Bernd > > > On 01/29/2018 07:56 PM, Evgenii Stepanov wrote: >> This is a report from an interceptor, it is not affected by blacklist, >> unfortunately. >> You could try MSAN_OPTIONS=intercept_strlen=0, but it is likely that >> something else will pop up instead. >> Try figuring out what is the actual reason for the report, i.e. what >> code is supposed to initialize this memory. Is it some other library >> that can be built with MSan? >> >> A better place for such questions is >> https://github.com/google/sanitizers/issues >> >> On Mon, Jan 29, 2018 at 5:59 AM, Bernd Schubert via cfe-users >> wrote: >>> Hello, >>> >>> I would like to blacklist some warnings, but everything I tried >>> so far is ignored. >>> >>> # cat msan-blacklist.txt >>> fun:*interceptor_strlen* >>> fun:*foreach_dirinpath* >>> fun:foreach_dirinpath >>> fun:*interceptor_strrchr* >>> fun:*try_dlopen* >>> src:*/ltdl.c >>> src:ltdl.c >>> >>> So I tried to blacklist all kind of combinations of the failing >>> functions and also of the related file - without success. It always >>> fails with the same issue. >>> >>> >>> >>> Uninitialized bytes in __interceptor_strlen at offset 0 inside >>> [0x70335370, 45) >>> ==3968020==WARNING: MemorySanitizer: use-of-uninitialized-value >>> #0 0x7f0f587fa099 in foreach_dirinpath >>> /home/bschubert/src/cci/gerrit/src/libltdl/ltdl.c:699:18 >>> [...] >>> >>> Uninitialized value was created by a heap allocation >>> #0 0x453ebd in __interceptor_malloc (/tmp/ime-server-bernd.0+0x453ebd) >>> #1 0x7f0f568c0f7e in __argz_create_sep (/usr/lib64/libc.so.6+0x90f7e) >>> #2 0x7f0f585f7775 in _dl_fixup (/lib64/ld-linux-x86-64.so.2+0xe775) >>> >>> SUMMARY: MemorySanitizer: use-of-uninitialized-value >>> /home/bschubert/src/cci/gerrit/src/libltdl/ltdl.c:699:18 in >>> foreach_dirinpath >>> Exiting >>> >>> >>> libcci and the main project I'm working on is compiled liked this >>> >>> libtool: compile: /opt/llvm-5.0.1/bin/clang -DHAVE_CONFIG_H -I. >>> -DLTDLOPEN=libltdlc "-DLT_CONFIG_H=" -DLTDL -I. -I. -Ilibltdl >>> -I./libltdl -I./libltdl -ggdb3 -O2 -fsanitize=memory >>> -fsanitize-memory-track-origins -fsanitize-memory-use-after-dtor >>> -fsanitize-blacklist=msan-blacklist.txt -MT libltdlc_la-lt_dlloader.lo >>> -MD -MP -MF .deps/libltdlc_la-lt_dlloader.Tpo -c lt_dlloader.c -fPIC >>> -DPIC -o .libs/libltdlc_la-lt_dlloader.o >>> >>> >>> Any ideas? >>> >>> >>> Thanks, >>> Bernd >>> ___ >>> cfe-users mailing list >>> cfe-users@lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users ___ cfe-users mailing list cfe-users@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
