Closed derekbruening closed 4 years ago
Well as part of rebuilding all the libraries I pulled in a newer version of the libelftc sources, and it is now asserting in our test:
194: Failed to unmangle xmlRelaxNGParseImportRefs
194: Failed to unmangle xmlRelaxNGParseImportRefs
194: libelftc_dem_gnu3.c:2138: cpp_demangle_read_sname: Assertion `ddata->output.size > 0' failed.
Plus, I move the redirect routines to be cross-platform, and now Windows crashes using them:
00 000000de`0294e190 00000000`151ab2d4 dynamorio!common_heap_free+0x1f7 [d:\derek\dr\git\src\core\heap.c @ 4488]
01 000000de`0294e340 00000000`1518c2f7 dynamorio!common_global_heap_free+0x84 [d:\derek\dr\git\src\core\heap.c @ 3470]
02 000000de`0294e380 00000000`1522d4a7 dynamorio!global_heap_free+0x37 [d:\derek\dr\git\src\core\heap.c @ 3511]
03 000000de`0294e3c0 00000000`1524efd3 dynamorio!redirect_free+0x37 [d:\derek\dr\git\src\core\loader_shared.c @ 997]
04 000000de`0294e3f0 00007ff6`1f22d54d dynamorio!__wrap_free+0x13 [d:\derek\dr\git\src\core\lib\instrument.c @ 3254]
05 000000de`0294e420 00007ff6`1f227da3 drsyms!vector_str_dest+0x2d [d:\derek\dr\libelftc\libelftc\libelftc_vstr.c @ 76]
06 000000de`0294e450 00007ff6`1f222c00 drsyms!cpp_demangle_gnu3+0x233 [d:\derek\dr\libelftc\libelftc\libelftc_dem_gnu3.c @ 235]
07 000000de`0294e540 00007ff6`1f1d519b drsyms!elftc_demangle+0x70 [d:\derek\dr\libelftc\libelftc\elftc_demangle.c @ 93]
08 000000de`0294e570 00007ff6`1f1d167b drsyms!drsym_unix_demangle_symbol+0x9b [d:\derek\dr\git\src\ext\drsyms\drsyms_unix_common.c @ 651]
09 000000de`0294e7c0 00007ff6`1f173c1f drsyms!drsym_demangle_symbol+0x6b [d:\derek\dr\git\src\ext\drsyms\drsyms_windows.c @ 1529]
0a 000000de`0294e800 00007ff6`1f171c35 client_drsyms_test_dll!test_demangle_symbols+0x6f [d:\derek\dr\git\src\suite\tests\client-interface\drsyms-test.dll.cpp @ 1151]
0b 000000de`0294f050 00007ff6`1f171091 client_drsyms_test_dll!test_demangle+0x15 [d:\derek\dr\git\src\suite\tests\client-interface\drsyms-test.dll.cpp @ 1201]
0c 000000de`0294f080 00000000`1524676a client_drsyms_test_dll!dr_init+0x91 [d:\derek\dr\git\src\suite\tests\client-interface\drsyms-test.dll.cpp @ 95]
0d 000000de`0294f0d0 00000000`150109a0 dynamorio!instrument_init+0x26a [d:\derek\dr\git\src\core\lib\instrument.c @ 773]
0e 000000de`0294f170 00000000`1533f31e dynamorio!dynamorio_app_init+0x6e0 [d:\derek\dr\git\src\core\dynamo.c @ 680]
Grrr, this was supposed to be easy.
Is the assert a bug? Or are we using the library incorrectly somehow? Should I just revert to the prior version? And bail on updating Windows to have direct calls? Without them it would go through the Rtl heap and be redirected there, right? Why doesn't that hit a problem? Is there sthg wrong in our wrappers?
The Windows crash is from strdup not being intercepted. Once I rebuild with that redirected, Windows hits the same assert as Linux (though it surfaces as an assert during a callback raised during assert reporting).
The assert is from libelftc r3531. That change does fix the failure to mangle _ZN10linked_ptrIN12CrxInstaller14WhitelistEntryEE4copyIS1_EEvPKS_IT_E
in drsyms-test, but then asserts on _ZZN7WebCore19SVGAnimatedProperty20LookupOrCreateHelperINS_32SVGAnimatedStaticPropertyTearOffIbEEbLb1EE21lookupOrCreateWrapperEPNS_10SVGElementEPKNS_15SVGPropertyInfoERbE19__PRETTY_FUNCTION__
which worked previously. It does not look like a simple bug to quickly work around or fix. I think we have to revert back to r3530, rebuild all the libraries with that, and file a bug vs libelftc. The old graceful failure is much better than an assert that will turn into memory corruption in release build.
drcachesim wants to support embedded static linkage use, and thus avoids malloc at runtime. When -record_heap is used it violates that:
One way to solve would be to replace malloc in our copy of libelftc and rebuild it, using ld -wrap or the pre-processor or maybe a patch. It will work w/ standalone, and the recent static lib change will re-route DR allocs back to malloc.