[llvm-dev] JIT and atexit crash (original) (raw)

Alex Denisov via llvm-dev llvm-dev at lists.llvm.org
Sun Nov 19 15:22:49 PST 2017

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:

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>

More information about the llvm-dev mailing list