[LLVMdev] LLVM optimization passes crash when running on second thread

[Eli Friedman]

On Tue, Mar 22, 2011 at 11:51 AM, Peter Zion
<peter.zion at fabric-engine.com> wrote:
> Hello,
>
> I am trying to modify my LLVM-based compiler to perform an initial, no-optimization compilation synchronously on startup and then perform an asynchronous, optimized recompilation in the background, and I am getting in one of the optimization passes.
>
> - I am using the official release of LLVM 2.8
> - I have compiled LLVM with threading enabled; I am running llvm::llvm_start_multithreaded() on application startup and checking that that result is true.
> - The foreground compilation works fine.
> - The background compilation also works fine if I comment out the addition of the optimization passes.
> - The optimization passes are being added as follows:
>        llvm::OwningPtr<llvm::PassManager> passManager( new llvm::PassManager );
>        if ( optimize )
>        {
>          llvm::createStandardFunctionPasses( passManager.get(), 2 );
>          llvm::createStandardModulePasses( passManager.get(), 2, false, true, true, true, false, llvm::createFunctionInliningPass() );
>          llvm::createStandardLTOPasses( passManager.get(), true, true, false );
>        }
>        passManager->run( *module );
> - If I *don't* comment out the optimization passes (inside the if statement above) LLVM crashes with what appears to be a stack overflow; I've attached the stack trace below.
> - The code above is in the Fabric::DG::Code::compileAST() function shown in the stack trace below; its child in the stack is the passManager->run() call.
> - I have added a global mutex lock around all my accesses to LLVM, just to try to debug the problem, and it doesn't make any difference.
> - Both compilations are using the same LLVMContext.  It is unclear from the LLVM docs whether this is allowed.  I would be surprised, however, if the global lock I added wouldn't have sorted out that issue if it was the problem.
> - In case it makes any difference, I am running on OS X and using Grand Central Dispatch to execute the background compilation using dispatch_group_async_f()
>
> Is this a known problem?  Can anyone suggest anything I can do to fix or further debug this problem?

My best guess is that your background thread has less stack space than
the main thread.  The version of LazyValueInfo which is in 2.8 was
recursive, and can use a lot of stack space in extreme cases (this was
fixed for 2.9, which should be released soon).  If you need to use
2.8, I would suggest either allocating more stack space, or
customizing the passes you use not to include -jump-threading and
-correlated-propagation.

-Eli