search for: cxa_finalize_ranges

Displaying 4 results from an estimated 4 matches for "cxa_finalize_ranges".

2017 Nov 19
2
JIT and atexit crash
...at some address 0xdeadbeef. Everything is fine, but when the host program (the one that JITs C++ code) shuts down, then I see a crash: error: memory read failed for 0xdeadbeef With the following backtrace: * frame #0: 0x000000010b70b7a0 frame #1: 0x00007fff8ae0c17f libsystem_c.dylib`__cxa_finalize_ranges + 339 frame #2: 0x00007fff8ae0c4b2 libsystem_c.dylib`exit + 55 frame #3: 0x00007fff8ad7723c libdyld.dylib`start + 8 After some debugging I think I understand what goes wrong. Here is my hypothesis: JIT allocates and maps some memory for the execution. Some function X at address 0xdeadbeef...
2017 Nov 21
2
JIT and atexit crash
...ory for the execution. Some function X at address 0xdeadbeef is part of this memory. >> JIT calls a code that passes the X to atexit. >> JIT deallocates and unmaps the memory used for execution (either via objectLayer.removeObjectSet or by calling JIT's destructors) >> atexit (cxa_finalize_ranges) calls the X at 0xdeadbeef which does not belong to 'us' anymore, which leads to the crash. > > Sounds plausible. > >> Given that my assumption is correct what can we do about this? Is there >> anything that can be done to cover this case inside of the Orc engine? &gt...
2017 Nov 23
2
JIT and atexit crash
...ress 0xdeadbeef is part of this memory. > >> JIT calls a code that passes the X to atexit. > >> JIT deallocates and unmaps the memory used for execution > (either via objectLayer.removeObjectSet or by calling JIT's > destructors) > >> atexit (cxa_finalize_ranges) calls the X at 0xdeadbeef which > does not belong to 'us' anymore, which leads to the crash. > > > > Sounds plausible. > > > >> Given that my assumption is correct what can we do about this? > Is there > >> anything that...
2017 Nov 23
1
JIT and atexit crash
...art of this memory. >> >> JIT calls a code that passes the X to atexit. >> >> JIT deallocates and unmaps the memory used for execution >> (either via objectLayer.removeObjectSet or by calling JIT's >> destructors) >> >> atexit (cxa_finalize_ranges) calls the X at 0xdeadbeef which >> does not belong to 'us' anymore, which leads to the crash. >> > >> > Sounds plausible. >> > >> >> Given that my assumption is correct what can we do about this? >> Is there >&gt...