Hi everyone, hi Lang,
I have a question about Orc JIT (and I think LLVM JIT in general).
I am jitting some C++ code that calls atexit and registers a function 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 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.
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?
Currently, I worked around this problem by resolving atexit to my custom
function that does nothing.
RuntimeDyld::SymbolInfo findSymbol(const std::string &Name) {
if (Name == "_atexit") {
return findSymbol("mull_custom_test_at_exit");
}
if (auto SymAddr = RTDyldMemoryManager::getSymbolAddressInProcess(Name))
return RuntimeDyld::SymbolInfo(SymAddr, JITSymbolFlags::Exported);
return RuntimeDyld::SymbolInfo(nullptr);
}
extern "C" int mull_custom_test_at_exit(void (* p)(void)) {
return atexit(p);
}
The solution removes the crash, but it is not optimal.
Best regards,
Alex.
--
https://lowlevelbits.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: Message signed with OpenPGP
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20171120/448d3991/attachment.sig>
On Mon, Nov 20, 2017 at 12:22:49AM +0100, Alex Denisov via llvm-dev wrote:> JIT allocates and maps some memory 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?It's not the job of the Orc engine. Just don't use atexit. Joerg
> It's not the job of the Orc engine.I could argue about this, but I won’t :)> Just don't use atexit.The problem is that I run third-party programs. I cannot control them.> On 20. Nov 2017, at 01:04, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Mon, Nov 20, 2017 at 12:22:49AM +0100, Alex Denisov via llvm-dev wrote: >> JIT allocates and maps some memory 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? > > It's not the job of the Orc engine. Just don't use atexit. > > Joerg > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 529 bytes Desc: Message signed with OpenPGP URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171121/b7fef120/attachment.sig>