[Bug sanitizer/110876] New: AddressSanitizer: false positive bad-free

[Bug sanitizer/110876] New: AddressSanitizer: false positive bad-free

[dvirtz at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110876

            Bug ID: 110876
           Summary: AddressSanitizer: false positive bad-free
           Product: gcc
           Version: 13.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dvirtz at gmail dot com
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

Using ASAN together with boost::test, where the test calls `std::abort`
produces the false diagonstic

=================================================================
==1==ERROR: AddressSanitizer: attempting free on address which was not
malloc()-ed: 0x625000002900 in thread T0
    #0 0x7f535efcb098 in operator delete[](void*)
(/opt/compiler-explorer/gcc-13.1.0/lib64/libasan.so.8+0xdc098) (BuildId:
c9b24be17e4cbd04bdb4891782c4425e47a9259a)
    #1 0x4ef5d8 in void boost::checked_array_delete<char>(char*)
/opt/compiler-explorer/libs/boost_1_82_0/boost/core/checked_delete.hpp:43
    #2 0x4c74d9 in boost::scoped_array<char>::~scoped_array()
/opt/compiler-explorer/libs/boost_1_82_0/boost/smart_ptr/scoped_array.hpp:70
    #3 0x49b22d in boost::execution_monitor::~execution_monitor()
/opt/compiler-explorer/libs/boost_1_82_0/boost/test/execution_monitor.hpp:317
    #4 0x4a9cd1 in
boost::unit_test::unit_test_monitor_t::~unit_test_monitor_t()
/opt/compiler-explorer/libs/boost_1_82_0/boost/test/unit_test_monitor.hpp:52
    #5 0x7f535e96a8a6  (/lib/x86_64-linux-gnu/libc.so.6+0x468a6) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
    #6 0x7f535e96aa5f in exit (/lib/x86_64-linux-gnu/libc.so.6+0x46a5f)
(BuildId: 1878e6b475720c7c51969e69ab2d276fae6d1dee)
    #7 0x7f535e948089 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24089) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
    #8 0x407e3d in _start (/app/output.s+0x407e3d) (BuildId:
672eb81700f7ac2665b4ac944a33b70100145f2e)

0x625000002900 is located 2048 bytes after 8192-byte region
[0x625000000100,0x625000002100)
freed by thread T0 here:
    #0 0x7f535efcb098 in operator delete[](void*)
(/opt/compiler-explorer/gcc-13.1.0/lib64/libasan.so.8+0xdc098) (BuildId:
c9b24be17e4cbd04bdb4891782c4425e47a9259a)
    #1 0x4ef5d8 in void boost::checked_array_delete<char>(char*)
/opt/compiler-explorer/libs/boost_1_82_0/boost/core/checked_delete.hpp:43
    #2 0x4c74d9 in boost::scoped_array<char>::~scoped_array()
/opt/compiler-explorer/libs/boost_1_82_0/boost/smart_ptr/scoped_array.hpp:70
    #3 0x49b22d in boost::execution_monitor::~execution_monitor()
/opt/compiler-explorer/libs/boost_1_82_0/boost/test/execution_monitor.hpp:317
    #4 0x49b5f1 in boost::unit_test::framework::state::~state()
/opt/compiler-explorer/libs/boost_1_82_0/boost/test/impl/framework.ipp:499
    #5 0x7f535e96a8a6  (/lib/x86_64-linux-gnu/libc.so.6+0x468a6) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)

previously allocated by thread T0 here:
    #0 0x7f535efca688 in operator new[](unsigned long)
(/opt/compiler-explorer/gcc-13.1.0/lib64/libasan.so.8+0xdb688) (BuildId:
c9b24be17e4cbd04bdb4891782c4425e47a9259a)
    #1 0x423222 in boost::execution_monitor::catch_signals(boost::function<int
()> const&)
/opt/compiler-explorer/libs/boost_1_82_0/boost/test/impl/execution_monitor.ipp:891
    #2 0x423794 in boost::execution_monitor::execute(boost::function<int ()>
const&)
/opt/compiler-explorer/libs/boost_1_82_0/boost/test/impl/execution_monitor.ipp:1301
    #3 0x4254ab in boost::execution_monitor::vexecute(boost::function<void ()>
const&)
/opt/compiler-explorer/libs/boost_1_82_0/boost/test/impl/execution_monitor.ipp:1397
    #4 0x41ae5f in
boost::unit_test::framework::init(boost::unit_test::test_suite* (*)(int,
char**), int, char**)
/opt/compiler-explorer/libs/boost_1_82_0/boost/test/impl/framework.ipp:1209
    #5 0x43eb06 in
boost::unit_test::unit_test_main(boost::unit_test::test_suite* (*)(int,
char**), int, char**)
/opt/compiler-explorer/libs/boost_1_82_0/boost/test/impl/unit_test_main.ipp:208
    #6 0x43f6a6 in main
/opt/compiler-explorer/libs/boost_1_82_0/boost/test/impl/unit_test_main.ipp:306
    #7 0x7f535e948082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)

SUMMARY: AddressSanitizer: bad-free
(/opt/compiler-explorer/gcc-13.1.0/lib64/libasan.so.8+0xdc098) (BuildId:
c9b24be17e4cbd04bdb4891782c4425e47a9259a) in operator delete[](void*)
==1==ABORTING


The same code runs without sanitizer errors when compiled with gcc 12.3

See https://godbolt.org/z/G4rbo8cGd

[Bug sanitizer/110876] AddressSanitizer: false positive bad-free

[dvirtz at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110876

--- Comment #1 from Dvir Yitzchaki <dvirtz at gmail dot com> ---
Created attachment 55676
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55676&action=edit
preprocessed code

[Bug sanitizer/110876] AddressSanitizer: false positive bad-free

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110876

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
clang trunk has the same failure.
clang 11.0.0 has the same failure.
clang 10.0.0 references https://github.com/google/sanitizers/issues/189 .

I am thinking this is boost issue because both clang and GCC producing the
error.

[Bug sanitizer/110876] AddressSanitizer: false positive bad-free

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110876

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I looked into the code and I think this is a boost issue, it is specifically
catching the abort signal and recovering and then exit is called and messes up.

[Bug sanitizer/110876] AddressSanitizer: false positive bad-free

[dvirtz at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110876

--- Comment #4 from Dvir Yitzchaki <dvirtz at gmail dot com> ---
Thanks @Andrew. 
Is it undefined behavior to recover from SIGABRT? I didn't find a source for
that.
The fact is that the memory ASAN is complaining about was allocated.