missing callstack frame leads to known mingw leak not matching suppression

_From [bruen...@google.com](https://code.google.com/u/109494838902877177630/) on April 04, 2014 18:07:32_

Running tests/cs2bugMinGW.exe on any platform, when built with MinGW gcc 4.7.3:

Error `#19`: LEAK 8 direct bytes 0x014c8600-0x014c8608 + 0 indirect bytes
#0 replace_malloc [d:\drmemory_package\common\alloc_replace.c:2320]
#1 __cxa_get_globals [/usr/src/debug/mingw-gcc-4.7.3-1/libstdc++-v3/libsupc++/eh_globals.cc:132]
#2 main [D:/derek/drmemory/git/src/tests/cs2bug.cpp:245]

This is supposed to be suppressed by the issue #1043 default supp, but we're
missing the __cxa_allocate_exception frame (plus the test_exception frame).

-no_callstack_use_fp => we get the callstack right and we suppress it.

I'm confused about what changed though: we tightened up fp walking for issue #703 and just enabled adding the lack of top fp for chrome, right? So
what caused this to regress? Running prior DrMem releases: 1.6.1 and
1.6.0 show this, so more likely it's a change in the mingw compiler.

It's classic issue #703 . test_exception pushes the prior fp, but neither
__cxa_allocate_exception nor __cxa_get_globals does, so replace_malloc ends
up pushing an fp that points back to main. The program was built
-fno-omit-frame-pointer but this is boilerplate code coming from somewhere
else.

Since I closed issue #703 having solved some of its instances that involve
cross-module transitions, I'm filing a new case.

Here are the details:

initial fp=0x0028fe48 vs sp=0x0028fcb8 def=1
find_next_fp b/c starting w/ non-fp ebp 0x0028fe48 (def=1 1)
check_retaddr_targets_frame: checking does 0x0045c0dc => 0x73940c50
find_next_fp 0x0028fcb8 => 0x0028fe48, ra=0x0045c0dc
print_callstack: pc=0x0028fe48 => FP=0x0028feb8, RA=0x0045c0dc <== __cxa_get_globals
check_retaddr_targets_frame: checking does 0x00401ed9 => 0x0045c0dc
print_callstack: pc=0x0028feb8 => FP=0x0028fed8, RA=0x00401ed9 <== main

callstack stack pc=0x73940c50 xsp=0x0028fcb8 xbp=0x0028fe48:
0x0028fcb8 0x0028fee8
...
0x0028fe48 0x0028feb8
0x0028fe4c 0x0045c0dc cs2bugMinGW.exe!__cxa_get_globals
0x0028fe50 0x00000008
0x0028fe54 0x1d91d680
0x0028fe58 0x00000000
0x0028fe5c 0x0028feb8
0x0028fe60 0x73a154ce drmemorylib.dll!replace_native_xfer
0x0028fe64 0x00000000
0x0028fe68 0x013e95b8
0x0028fe6c 0x0045baf9 cs2bugMinGW.exe!__cxa_allocate_exception
0x0028fe70 0x00000064
0x0028fe74 0x004680a1 cs2bugMinGW.exe!.rdata
0x0028fe78 0x00000012
0x0028fe7c 0x0028feb8
0x0028fe80 0x0028fee9
0x0028fe84 0x00797326
0x0028fe88 0x0028fee8
0x0028fe8c 0x00401aa3 cs2bugMinGW.exe!test_exception
0x0028fe90 0x00000004
0x0028fe94 0x004680a1 cs2bugMinGW.exe!.rdata
0x0028fe98 0x00797326
0x0028fe9c 0x00000000
0x0028fea0 0x004097c0 cs2bugMinGW.exe!__do_global_dtors
0x0028fea4 0x0028fe90
0x0028fea8 0x013e9578
0x0028feac 0x013e94d0
0x0028feb0 0x00797326
0x0028feb4 0x0028fee9
0x0028feb8 0x0028fed8
0x0028febc 0x00401ed9 cs2bugMinGW.exe!main

(gdb) x/4i 0x0045c0dc-5
0x45c0d7 <__cxxabiv1::__cxa_get_globals()+55>: call 0x413c90

If we had symbols at callstack walk time I'd say don't trust the fp of a
function that starts with "__".

_Original issue: http://code.google.com/p/drmemory/issues/detail?id=1509_