https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87840
chefmax at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |chefmax at gcc dot gnu.org
--- Comment #10 from chefmax at gcc dot gnu.org ---
(In reply to Jan Engelhardt from comment #0)
> $ cat x.cpp
> #include <memory>
> struct S {
> std::shared_ptr<S> other;
> };
> int main()
> {
> auto e = std::make_shared<S>();
> e->other = e;
> }
>
> $ g++-9 x.cpp -ggdb3 -llsan -fsanitize=leak
> $ ./a.out
> $
>
> LSAN fails to report the cycle while valgrind does.
>
> Using built-in specs.
> COLLECT_GCC=g++-9
> COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/9/lto-wrapper
> OFFLOAD_TARGET_NAMES=hsa:nvptx-none
> Target: x86_64-suse-linux
> Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
> --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
> --enable-languages=c,c++,objc,fortran,obj-c++,ada,go
> --enable-offload-targets=hsa,nvptx-none=/usr/nvptx-none,
> --without-cuda-driver --enable-checking=release --disable-werror
> --with-gxx-include-dir=/usr/include/c++/9 --enable-ssp --disable-libssp
> --disable-libvtv --disable-cet --disable-libcc1 --enable-plugin
> --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
> --with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
> --disable-libstdcxx-pch --enable-version-specific-runtime-libs
> --with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex
> --enable-gnu-indirect-function --program-suffix=-9
> --without-system-libunwind --enable-multilib --with-arch-32=x86-64
> --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux
> Thread model: posix
> gcc version 9.0.0 20181026 (experimental) [trunk revision 265522] (SUSE
> Linux)
> Applies to
> gcc version 8.2.1 20180831 [gcc-8-branch revision 264010] (SUSE Linux)
> gcc version 7.3.1 20180817 [gcc-7-branch revision 263612] (SUSE Linux)
> as well.
I can confirm this with master GCC:
$ ~/install/master/bin/g++ x.cpp -ggdb3 -fsanitize=leak -static-liblsan ;
LSAN_OPTIONS=log_pointers=1:log_threads=1 ./a.out
==9273==Scanning GLOBAL range 0x000000651000-0x000000654fe0.
==9273==Scanning GLOBAL range 0x0000006552a8-0x000000ee86e8.
==9273==Scanning GLOBAL range 0x7fa92c405308-0x7fa92c4140a0.
==9273==0x7fa92c410ca8: found 0x631000000000 pointing into chunk
0x631000000000-0x631000011c00 of size 72704.
==9273==Scanning GLOBAL range 0x7fa92c090d70-0x7fa92c0910f8.
==9273==Scanning GLOBAL range 0x7fa92bd87d60-0x7fa92bd880f0.
==9273==Scanning GLOBAL range 0x7fa92bb83d58-0x7fa92bb84bc0.
==9273==Scanning GLOBAL range 0x7fa92b977b78-0x7fa92b97c428.
==9273==Scanning GLOBAL range 0x7fa92b75edc8-0x7fa92b75f450.
==9273==Scanning GLOBAL range 0x7fa92b53f7c0-0x7fa92b5489a0.
==9273==Scanning GLOBAL range 0x7fa92c63abc0-0x7fa92c63c168.
==9273==Processing thread 9272.
==9273==Scanning REGISTERS range 0x7fa92c5ff000-0x7fa92c5ff0d8.
==9273==Stack at 0x7ffe51e77000-0x7ffe52677000 (SP = 0x7ffe52674a28).
==9273==Scanning STACK range 0x7ffe52674a28-0x7ffe52677000.
==9273==0x7ffe52674bf8: found 0x602000000008 pointing into chunk
0x602000000000-0x602000000020 of size 32.
==9273==TLS at 0x7fa92c5e2000-0x7fa92c5f0c00.
==9273==Scanning TLS range 0x7fa92c5e2000-0x7fa92c5e2758.
==9273==Scanning TLS range 0x7fa92c5f02d8-0x7fa92c5f0c00.
==9273==Scanning HEAP range 0x602000000000-0x602000000020.
==9273==Scanning HEAP range 0x631000000000-0x631000011c00.
==9273==Processing platform-specific allocations.
==9273==Scanning leaked chunks
>From the log I can see that pointer to allocated chunk still reachable from
main thread stack.
I'm not sure why this doesn't happen with ASan enabled, perhaps it performs
some stack cleanup before exit and rewrites this pointer.
Anyways, I don't see any opportunity to fix this in LSan in its current usage
model.
FWIW upstream has several similar reports, see e.g.
https://github.com/google/sanitizers/issues/937
