Red Hat Bugzilla – Bug 1468909
gcc + asan + exceptions = stack-use-after-scope false positive
Last modified: 2017-09-19 11:36:32 EDT
Description of problem: gcc 7 Address Sanitizer warns about false positives Version-Release number of selected component (if applicable): gcc-7.1.1-3.fc26.x86_64 How reproducible: Always Steps to Reproduce: 1. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021 Actual results: False error detected. Expected results: No false error Additional info: This was fixed on gcc trunk, so this is just a request to backport into Fedora.
I can reproduce this issue with a relatively simple unittest case - one that uses the Boost unittest framework library (UTF). ==8426==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7ffcc390b8c0 at pc 0x00000057ad7e bp 0x7ffcc390b760 sp 0x7ffcc390b750 WRITE of size 32 at 0x7ffcc390b8c0 thread T0 #1 0x5f1eb1 in maildir::flags_except::test_method() ../unittest/maildir.cc:149 #2 0x5f08b2 in flags_except_invoker ../unittest/maildir.cc:134 The test checks if an exception is thrown: bool caught = false; try { m.move_to_cur("XYZ"); } catch (std::runtime_error) { caught = true; } BOOST_CHECK_EQUAL(caught, true); The last line is line 149 from the adress sanitizer error report. The code isn't multi-threaded. (Yes, I know that the UTF includes some specialized assertion macros for checking if an exception was thrown.)
Are you/is anybody able to disable the check with `ASAN_OPTIONS=detect_stack_use_after_scope=0`? [1] https://github.com/google/sanitizers/wiki/AddressSanitizerExampleUseAfterScope
No, I am not able to disable the check with that option. That means when I call my unittest binary like this: ASAN_OPTIONS=detect_stack_use_after_scope=0 ./ut --run_test=maildir/flags_except then I still get: ==4323==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fff5b2fb1c0 at pc 0x00000057ad7e bp 0x7fff5b2fb060 sp 0x7fff5b2fb050 WRITE of size 32 at 0x7fff5b2fb1c0 thread T0 FWIW, clang+asan works as expected on those unittests. (modulo some non-whitelisted pseudo leaks in libstdc++)
This was fixed in gcc 7.2. An update would be appreciated. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81021
gcc 7.2 has landed in F26 via updates. Tested and behaves nicely now. Think this here can be closed now.