[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