Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[WSL1] LeakSanitizer always encounters fatal error on exit with any cpp compiled with g++. #6304

Closed
hbirler opened this issue Dec 3, 2020 · 3 comments

Comments

@hbirler
Copy link

hbirler commented Dec 3, 2020

Environment

Windows build number: Microsoft Windows [Version 10.0.18363.1198]
Distribution version: Ubuntu 20.10
g++: (Ubuntu 10.2.0-13ubuntu1) 10.2.0
clang++: Ubuntu clang version 11.0.0-2
Running on WSL 1

Steps to reproduce

Compile & execute main.cpp with contents int main() {return 0;} with -fsanitize=leak using the following commands:

echo "int main() {return 0;}" > main.cpp
g++ -fsanitize=leak main.cpp -o main.out
LSAN_OPTIONS=verbosity=1:log_threads=1 ./main.out

Expected behavior

No errors are expected since this is the simplest possible empty cpp file.

Actual behavior

LeakSanitizer encounters a fatal error on every .cpp I have tried when compiling with -fsanitize=leak.

The command exits with non-zero status and has the following output:

==10034==Installed the sigaction for signal 11
==10034==Installed the sigaction for signal 7
==10034==Installed the sigaction for signal 8
==10035==Processing thread 10034.
==10035==Stack at 0x7fffe601a000-0x7fffe681a000 (SP = 0x7fffe6817ea8).
==10035==TLS at 0x7fbb15b0ff40-0x7fbb15b1ebc0.
Tracer caught signal 11: addr=0x7fbb15b0ff40 pc=0x7fbb15d788a0 sp=0x7fbb149f0ce0
==10034==LeakSanitizer has encountered a fatal error.
==10034==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1
==10034==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)

I believe signal 11 stands for segmentation fault. Trying to debug with gdb and LSAN_OPTIONS=verbosity=1:log_threads=1:abort_on_error=1 results in an abort with the following call stack:

#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:49
#1  0x00007ffffecd6864 in __GI_abort () at abort.c:79
#2  0x00007ffffeebfd32 in ?? () from /lib/x86_64-linux-gnu/liblsan.so.0
#3  0x00007ffffeecb3ec in ?? () from /lib/x86_64-linux-gnu/liblsan.so.0
#4  0x00007ffffeeaa2bc in ?? () from /lib/x86_64-linux-gnu/liblsan.so.0
#5  0x00007ffffeeaa2f9 in ?? () from /lib/x86_64-linux-gnu/liblsan.so.0
#6  0x00007ffffecf518e in __cxa_finalize (d=0x7ffffeefb320) at cxa_finalize.c:83
#7  0x00007ffffeea6e87 in ?? () from /lib/x86_64-linux-gnu/liblsan.so.0
#8  0x00007ffffffed850 in ?? ()

The error seems to happen after main() is finished and the program is doing final cleanup.

Compiling with clang++ 11.0.0-2 on my machine on WSL1 results in the exact same output.

However, compiling with g++ 10.2 on ubuntu 20.10 on an actual linux machine does not result in this issue. That is why I suspect this might have something to do with WSL.

The strace can be found here:
https://gist.github.com/hbirler/37f84102cbd1dbfa519a98c9bcf9cadf

Compiling and running without -fsanitize results in no errors and the program exits with code 0.

@hbirler hbirler changed the title LeakSanitizer always encounters fatal error on exit with any cpp compiled with g++. WSL1 [WSL1] LeakSanitizer always encounters fatal error on exit with any cpp compiled with g++. Dec 3, 2020
@therealkenc
Copy link
Collaborator

Version 10.0.18363.1198

Thank-you for the concise report and strace log. Cannot reproduce on WSL1 20270:

image

There were improvements with respect to the sanitizer in #3589 that were assumed to make 1903 (aka 18363) but maybe it didn't. Call this fixed in WSL2 out of an abundance of caution. If it is fixed in WSL1 19042, so much the better ("that too").

@Po-wei
Copy link

Po-wei commented Dec 7, 2020

On my machine, test it with g++9.3.0 on both ubuntu18.04 and ubuntu20.04 on WSL1 with no error
windows Version 10.0.19042.662
image

@hbirler
Copy link
Author

hbirler commented Dec 10, 2020

Hi. I upgraded my machine to Windows 20.10 (Build 19042.685), did a clean install of Ubuntu 20.10 from https://cloud-images.ubuntu.com/groovy/current/groovy-server-cloudimg-arm64-wsl.rootfs.tar.gz with WSL 1 and retried with both g++-10 and g++-9 and the problem seems to persist.

LSAN_OPTIONS=verbosity=1:log_threads=1 ./main.out
==9070==Installed the sigaction for signal 11
==9070==Installed the sigaction for signal 7
==9070==Installed the sigaction for signal 8
==9071==Processing thread 9070.
==9071==Stack at 0x7fffc5cbb000-0x7fffc64bb000 (SP = 0x7fffc64b8588).
==9071==TLS at 0x7febfce5ff40-0x7febfce6ebc0.
Tracer caught signal 11: addr=0x7febfce5ff40 pc=0x7febfd0c88a0 sp=0x7febfbdf0ce0
==9070==LeakSanitizer has encountered a fatal error.
==9070==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1
==9070==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)

A signal 11 is still caught.

Here is the strace:
https://gist.github.com/hbirler/1b43ffe24a6a102f9daeec15ed4a1684

Some additional info:

> cat /proc/version
Linux version 4.4.0-19041-Microsoft (Microsoft@Microsoft.com) (gcc version 5.4.0 (GCC) ) #488-Microsoft Mon Sep 01 13:43:00 PST 2020
> g++ --version
g++ (Ubuntu 10.2.0-13ubuntu1) 10.2.0
> lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 20.10
Release:        20.10
Codename:       groovy

Cpu Model: Intel(R) Core(TM) i7-3630QM CPU @ 2.40GHz

I would be happy to dive deeper into debugging the issue myself, however, I am at a loss when it comes to how LSAN works, how WSL might cause an issue with LSAN and what in general could be the cause of such a problem. Any resources which I could learn from in order to debug this issue would also be appreciated.

Switching my Ubuntu installation to WSL2 solves the issue. So this is a WSL1 issue somehow. (I currently prefer to stay with WSL1 due to faster Windows FS performance.)

Switching to WSL1 once again results, as one would expect, in a signal 11 being caught.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants