[Bug other/87666] New: Memory access errors when using c++ 17 filesystem library and "-mcpu=cortex-a53"

christian_hoff at gmx dot net gcc-bugzilla@gcc.gnu.org
Sat Oct 20 17:37:00 GMT 2018


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

            Bug ID: 87666
           Summary: Memory access errors when using c++ 17 filesystem
                    library and "-mcpu=cortex-a53"
           Product: gcc
           Version: 8.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: other
          Assignee: unassigned at gcc dot gnu.org
          Reporter: christian_hoff at gmx dot net
  Target Milestone: ---

Created attachment 44865
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44865&action=edit
sample code and Makefile to reproduce the issue

I have the following simple test code that uses the C++ 17 filesystem library:

#include <filesystem>
#include <iostream>

namespace fs = std::filesystem;
using namespace std;

int main(int argc, char *argv[])
{
    fs::path dir = "/tmp";
    fs::directory_iterator dirIter(dir);
    for (const fs::directory_entry &entry : dirIter) {
        cout << "Found entry " << entry.path().filename() << endl;
    }
}

When compiling this code with GCC 8.2.0 on ARM platform with "-mcpu=cortex-a53"
and Address Sanitizer instrumentation Address Sanitizer reports a memory access
error (see below) when running the compiled executable. But if I omit the
"-mcpu=cortex-a53" and compile the code also with Address Sanitizer, I do not
get this memory access error. So whether I get the memory access error or not
depends on whether "-mcpu=cortex-a53" was specified on the command line or not.

I have attached a tar archive with the example code and a Makefile to build it.

The memory access error reported by Address Sanitizer looks as follows:

=================================================================
==2625==ERROR: AddressSanitizer: heap-use-after-free on address 0x74402e04 at
pc 0x001222f8 bp 0x7ebb0b74 sp 0x7ebb0b6c
WRITE of size 4 at 0x74402e04 thread T0
    #0 0x1222f7 in __exchange_and_add /usr/include/c++/8/ext/atomicity.h:49
    #1 0x122523 in __exchange_and_add_dispatch
/usr/include/c++/8/ext/atomicity.h:82
    #2 0x1261cf in
std::_Sp_counted_base<(__gnu_cxx::_Lock_policy)2>::_M_release()
/usr/include/c++/8/bits/shared_ptr_base.h:152
    #3 0x124b9b in
std::__shared_count<(__gnu_cxx::_Lock_policy)2>::~__shared_count()
/usr/include/c++/8/bits/shared_ptr_base.h:706
    #4 0x1233d3 in std::__shared_ptr<std::filesystem::__cxx11::_Dir,
(__gnu_cxx::_Lock_policy)2>::~__shared_ptr()
/usr/include/c++/8/bits/shared_ptr_base.h:1145
    #5 0x1233ff in
std::shared_ptr<std::filesystem::__cxx11::_Dir>::~shared_ptr()
/usr/include/c++/8/bits/shared_ptr.h:103
    #6 0x12342b in
std::filesystem::__cxx11::directory_iterator::~directory_iterator()
/usr/include/c++/8/bits/fs_dir.h:372
    #7 0x121edb in main
/home/pi/projects/sip/pjsip/directory-iterator-bug/Main.cpp:10
    #8 0x76b1d143 in __libc_start_main
(/lib/arm-linux-gnueabihf/libc.so.6+0x17143)

0x74402e04 is located 4 bytes inside of 124-byte region [0x74402e00,0x74402e7c)
freed by thread T0 here:
    #0 0xe19af in operator delete(void*)
(/home/pi/projects/sip/pjsip/directory-iterator-bug/demo+0xe19af)
    #1 0x12ead3 in std::filesystem::__cxx11::directory_iterator::operator++()
(/home/pi/projects/sip/pjsip/directory-iterator-bug/demo+0x12ead3)
    #2 0x76b1d143 in __libc_start_main
(/lib/arm-linux-gnueabihf/libc.so.6+0x17143)

previously allocated by thread T0 here:
    #0 0xe0ddb in operator new(unsigned int)
(/home/pi/projects/sip/pjsip/directory-iterator-bug/demo+0xe0ddb)
    #1 0x12d7ff in
std::filesystem::__cxx11::directory_iterator::directory_iterator(std::filesystem::__cxx11::path
const&, std::filesystem::directory_options, std::error_code*)
(/home/pi/projects/sip/pjsip/directory-iterator-bug/demo+0x12d7ff)
    #2 0x121c0b in main
/home/pi/projects/sip/pjsip/directory-iterator-bug/Main.cpp:10
    #3 0x76b1d143 in __libc_start_main
(/lib/arm-linux-gnueabihf/libc.so.6+0x17143)

SUMMARY: AddressSanitizer: heap-use-after-free
/usr/include/c++/8/ext/atomicity.h:49 in __exchange_and_add
Shadow bytes around the buggy address:
  0x2e880570: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x2e880580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x2e880590: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x2e8805a0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x2e8805b0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x2e8805c0:[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd
  0x2e8805d0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x2e8805e0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x2e8805f0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x2e880600: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
  0x2e880610: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:           00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:       fa
  Freed heap region:       fd
  Stack left redzone:      f1
  Stack mid redzone:       f2
  Stack right redzone:     f3
  Stack after return:      f5
  Stack use after scope:   f8
  Global redzone:          f9
  Global init order:       f6
  Poisoned by user:        f7
  Container overflow:      fc
  Array cookie:            ac
  Intra object redzone:    bb
  ASan internal:           fe
  Left alloca redzone:     ca
  Right alloca redzone:    cb
==2625==ABORTING

My GCC version is g++ (Raspbian 8.2.0-4+rpi1) 8.2.0


More information about the Gcc-bugs mailing list