llvm dev - Mar 2014 - [LLVMdev] MCJIT crash on 64 bit Linux, works find on OSX

Hi All.

I have an issue when a MCJIT ExecutionEngine is created then deleted, any C++
exception thrown after the MCJIT dtor is called will result in a seg fault. This
does not occur with the regular JIT engine, and only occurs on Linux, works fine
on OSX.

basically its like this:

ExecutionEngine *e = engineBuilder.create();

// this is fine
try { throw exception()} catch(exception&) {}

delete e

e = engineBuilder.create();

// this will cause a segfault on 64 bit Linux, LLVM 3.4
// works fine on OSX
try { throw exception()} catch(exception&) {}

Any ideas?

I get the same behavior with llvm 3.3

If I do not delete the ExecutionEngine, it works fine, and if I create a regular
JIT and delete it it works fine.

So, basically, if I just let the engines leak, it seems to work. 

After creating the engine, all I do is just build series of module function and
JIT the module. I add mappings to a number of C++ functions in my library each
time a new engine is created with:

void myAddGlobalMapping(const llvm::GlobalValue *gv, void *addr)
{
    llvm::sys::DynamicLibrary::AddSymbol(gv->getName(), addr);
    executionEngine->addGlobalMapping(gv, addr);
}





On Feb 28, 2014, at 9:32 PM, Andy Somogyi wrote:
> Hi All.
> 
> I have an issue when a MCJIT ExecutionEngine is created then deleted, any
C++ exception thrown after the MCJIT dtor is called will result in a seg fault.
This does not occur with the regular JIT engine, and only occurs on Linux, works
fine on OSX.
> 
> basically its like this:
> 
> ExecutionEngine *e = engineBuilder.create();
> 
> // this is fine
> try { throw exception()} catch(exception&) {}
> 
> delete e
> 
> e = engineBuilder.create();
> 
> // this will cause a segfault on 64 bit Linux, LLVM 3.4
> // works fine on OSX
> try { throw exception()} catch(exception&) {}
> 
> Any ideas?

Attached is a stack trace, the function, getFloatingSpeciesIndex() throws a
routine std::exception which is normally caught one level up in
LLVMModelSymbols::visit().

However, after a MCJIT ExecutionEngine is deleted and re-created, I think
something in the destructor might be removing part of the std c++ runtime, is
the even possible?

Again, like I said the exact same code works perfectly on 64 OSX 10.6 and it
works perfectly all platforms when using the regular JIT.


Thread [1] 9303 [core: 1] (Suspended : Signal : SIGSEGV:Segmentation fault)
	0x7ffff61eb751
	0x7ffff61ebca9
	_Unwind_Find_FDE() at 0x7ffff61eca72
	0x7ffff61e9c7c
	0x7ffff61ea63d
	_Unwind_RaiseException() at 0x7ffff61eaace
	__cxa_throw() at 0x7ffff644faa1
	rrllvm::LLVMModelDataSymbols::getFloatingSpeciesIndex() at
LLVMModelDataSymbols.cpp:262 0x7ffff6e537f5
	rrllvm::LLVMModelSymbols::visit() at LLVMModelSymbols.cpp:185 0x7ffff6e0300e

On Mar 1, 2014, at 12:48 AM, Andy Somogyi wrote:
> I get the same behavior with llvm 3.3
> 
> If I do not delete the ExecutionEngine, it works fine, and if I create a
regular JIT and delete it it works fine.
> 
> So, basically, if I just let the engines leak, it seems to work. 
> 
> After creating the engine, all I do is just build series of module function
and JIT the module. I add mappings to a number of C++ functions in my library
each time a new engine is created with:
> 
> void myAddGlobalMapping(const llvm::GlobalValue *gv, void *addr)
> {
>    llvm::sys::DynamicLibrary::AddSymbol(gv->getName(), addr);
>    executionEngine->addGlobalMapping(gv, addr);
> }
> 
> 
> 
> 
> 
> On Feb 28, 2014, at 9:32 PM, Andy Somogyi wrote:
> 
>> Hi All.
>> 
>> I have an issue when a MCJIT ExecutionEngine is created then deleted,
any C++ exception thrown after the MCJIT dtor is called will result in a seg
fault. This does not occur with the regular JIT engine, and only occurs on
Linux, works fine on OSX.
>> 
>> basically its like this:
>> 
>> ExecutionEngine *e = engineBuilder.create();
>> 
>> // this is fine
>> try { throw exception()} catch(exception&) {}
>> 
>> delete e
>> 
>> e = engineBuilder.create();
>> 
>> // this will cause a segfault on 64 bit Linux, LLVM 3.4
>> // works fine on OSX
>> try { throw exception()} catch(exception&) {}
>> 
>> Any ideas?
>