I'm working on a bad behaviour of my application ... I've recently upgraded my g++-4.1 to g++-4.8 and I'm experiencing memory overlaps between private members of some class instances and some variables globally defined in the main source.
Trapping the writeing with gdb and looking the variable pointers I can clarely see that they share the same memory address.
activating the -fsanitize=address introduced in the 4.8 I can see the same.
=================================================================
==5160== ERROR: AddressSanitizer: global-buffer-overflow on address 0x00000079750c at pc 0x4ba54f bp 0x7ffc0dc35df0 sp 0x7ffc0dc35de8
WRITE of size 1 at 0x00000079750c thread T0
#0 0x4ba54e (/opt/softplc/softplc+0x4ba54e)
#1 0x4bd988 (/opt/softplc/softplc+0x4bd988)
#2 0x4c1ea1 (/opt/softplc/softplc+0x4c1ea1)
#3 0x4ba7c5 (/opt/softplc/softplc+0x4ba7c5)
#4 0x409116 (/opt/softplc/softplc+0x409116)
#5 0x511cfc (/opt/softplc/softplc+0x511cfc)
#6 0x7fce6124de54 (/lib/x86_64-linux-gnu/libc-2.19.so+0x21e54)
#7 0x409c24 (/opt/softplc/softplc+0x409c24)
0x00000079750c is located 20 bytes to the left of global variable 'loopcounteryyyyyyy (softplc.cpp)' (0x797520) of size 8
'loopcounteryyyyyyy (softplc.cpp)' is ascii string ''
0x00000079750c is located 36 bytes to the right of global variable 'tod (softplc.cpp)' (0x7974e0) of size 8
'tod (softplc.cpp)' is ascii string ''
Shadow bytes around the buggy address:
0x0000800eae50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0000800eae60: 00 00 logger thread PID= 5160
00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0000800eae70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0x0000800eae80: 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
0x0000800eae90: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
=>0x0000800eaea0: f9[f9]f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
0x0000800eaeb0: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
0x0000800eaec0: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
0x0000800eaed0: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
0x0000800eaee0: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
0x0000800eaef0: f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9 00 f9 f9 f9
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
Heap righ redzone: fb
Freed Heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
ASan internal: fe
==5160== ABORTING
The code is really huge and when I try to cut parts of it in order to isolate the problem the overlapped region moves up to disappear.
Anyway, everything is defined statically, there are not instances defined runtime so, I think, the overlaps is a kind of mistake of the compiler or of the gcclib or I don't know who other else which allocates two different items on the same address. The question is: in which other way can I investigate and produce more useful information in order to track the reason of this "bug" ?
