[cfe-dev] Clang 'locks up' when compiling optimized

Wed Jun 28 07:55:33 PDT 2017

This the the stack trace when the compiler locked up.
I attached with ‘lldb -p <pid>”
I did the thread backtrace all then a process resume
I interrupted the program again and did a second thread backtrace all. Both were identical.

	David

(lldb) thread backtrace all
* thread #1: tid = 0x13b475b, 0x00007fff90ec65da libsystem_kernel.dylib`syscall_thread_switch + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
  * frame #0: 0x00007fff90ec65da libsystem_kernel.dylib`syscall_thread_switch + 10
    frame #1: 0x00007fff9497682d libsystem_platform.dylib`_OSSpinLockLockSlow + 63
    frame #2: 0x00007fff8ca7271b libsystem_malloc.dylib`szone_malloc_should_clear + 116
    frame #3: 0x00007fff8ca72667 libsystem_malloc.dylib`malloc_zone_malloc + 71
    frame #4: 0x00007fff8ca71187 libsystem_malloc.dylib`malloc + 42
    frame #5: 0x00007fff991fa43e libc++.1.dylib`operator new(unsigned long) + 30
    frame #6: 0x00007fff991fcf05 libc++.1.dylib`std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::__init(char const*, unsigned long) + 59
    frame #7: 0x000000010e6fc7a9 libLLVM.dylib`llvm::sys::findProgramByName(llvm::StringRef, llvm::ArrayRef<llvm::StringRef>) + 670
    frame #8: 0x000000010e6fd22c libLLVM.dylib`printSymbolizedStackTrace(llvm::StringRef, void**, int, llvm::raw_ostream&) + 186
    frame #9: 0x000000010e6fda7b libLLVM.dylib`llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 93
    frame #10: 0x000000010e6fd116 libLLVM.dylib`llvm::sys::RunSignalHandlers() + 83
    frame #11: 0x000000010e6fde4d libLLVM.dylib`SignalHandler(int) + 183
    frame #12: 0x00007fff94977f1a libsystem_platform.dylib`_sigtramp + 26
    frame #13: 0x00007fff8ca757da libsystem_malloc.dylib`szone_free_definite_size + 4827
    frame #14: 0x000000010eb8a45b libLLVM.dylib`std::__1::__tree<std::__1::__value_type<llvm::Value*, llvm::Optional<(anonymous namespace)::BitPart> >, std::__1::__map_value_compare<llvm::Value*, std::__1::__value_type<llvm::Value*, llvm::Optional<(anonymous namespace)::BitPart> >, std::__1::less<llvm::Value*>, true>, std::__1::allocator<std::__1::__value_type<llvm::Value*, llvm::Optional<(anonymous namespace)::BitPart> > > >::destroy(std::__1::__tree_node<std::__1::__value_type<llvm::Value*, llvm::Optional<(anonymous namespace)::BitPart> >, void*>*) + 41
    frame #15: 0x000000010eb8a44f libLLVM.dylib`std::__1::__tree<std::__1::__value_type<llvm::Value*, llvm::Optional<(anonymous namespace)::BitPart> >, std::__1::__map_value_compare<llvm::Value*, std::__1::__value_type<llvm::Value*, llvm::Optional<(anonymous namespace)::BitPart> >, std::__1::less<llvm::Value*>, true>, std::__1::allocator<std::__1::__value_type<llvm::Value*, llvm::Optional<(anonymous namespace)::BitPart> > > >::destroy(std::__1::__tree_node<std::__1::__value_type<llvm::Value*, llvm::Optional<(anonymous namespace)::BitPart> >, void*>*) + 29
    frame #16: 0x000000010eb8a44f libLLVM.dylib`std::__1::__tree<std::__1::__value_type<llvm::Value*, llvm::Optional<(anonymous namespace)::BitPart> >, std::__1::__map_value_compare<llvm::Value*, std::__1::__value_type<llvm::Value*, llvm::Optional<(anonymous namespace)::BitPart> >, std::__1::less<llvm::Value*>, true>, std::__1::allocator<std::__1::__value_type<llvm::Value*, llvm::Optional<(anonymous namespace)::BitPart> > > >::destroy(std::__1::__tree_node<std::__1::__value_type<llvm::Value*, llvm::Optional<(anonymous namespace)::BitPart> >, void*>*) + 29
    frame #17: 0x000000010eb894e0 libLLVM.dylib`llvm::recognizeBSwapOrBitReverseIdiom(llvm::Instruction*, bool, bool, llvm::SmallVectorImpl<llvm::Instruction*>&) + 1224
    frame #18: 0x000000010ec3f969 libLLVM.dylib`llvm::InstCombiner::MatchBSwap(llvm::BinaryOperator&) + 391
    frame #19: 0x000000010ec3fe7c libLLVM.dylib`llvm::InstCombiner::visitOr(llvm::BinaryOperator&) + 636
    frame #20: 0x000000010ec2e3a3 libLLVM.dylib`llvm::InstCombiner::run() + 1261
    frame #21: 0x000000010ec2f05c libLLVM.dylib`combineInstructionsOverFunction(llvm::Function&, llvm::InstCombineWorklist&, llvm::AAResults*, llvm::AssumptionCache&, llvm::TargetLibraryInfo&, llvm::DominatorTree&, bool, llvm::LoopInfo*) + 2431
    frame #22: 0x000000010ec2f2d7 libLLVM.dylib`llvm::InstructionCombiningPass::runOnFunction(llvm::Function&) + 297
    frame #23: 0x000000010e78e1ba libLLVM.dylib`llvm::FPPassManager::runOnFunction(llvm::Function&) + 290
    frame #24: 0x000000010ee59722 libLLVM.dylib`(anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) + 810
    frame #25: 0x000000010e78e6be libLLVM.dylib`llvm::legacy::PassManagerImpl::run(llvm::Module&) + 606
    frame #26: 0x000000010d26c481 clang`clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::HeaderSearchOptions const&, clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::DataLayout const&, llvm::Module*, clang::BackendAction, std::__1::unique_ptr<llvm::raw_pwrite_stream, std::__1::default_delete<llvm::raw_pwrite_stream> >) + 10253
    frame #27: 0x000000010d38e53d clang`clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 1035
    frame #28: 0x000000010d693f59 clang`clang::ParseAST(clang::Sema&, bool, bool) + 374
    frame #29: 0x000000010d4fa5bd clang`clang::FrontendAction::Execute() + 69
    frame #30: 0x000000010d4c89d0 clang`clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 722
    frame #31: 0x000000010d526144 clang`clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1976
    frame #32: 0x000000010d205d96 clang`cc1_main(llvm::ArrayRef<char const*>, char const*, void*) + 1371
    frame #33: 0x000000010d20503e clang`main + 8255
    frame #34: 0x00007fff979fb5c9 libdyld.dylib`start + 1
    frame #35: 0x00007fff979fb5c9 libdyld.dylib`start + 1
(lldb) 

> On Jun 27, 2017, at 7:20 AM, Brian Cain <brian.cain at gmail.com> wrote:
> 
> 
> On Tue, Jun 27, 2017 at 9:09 AM, David Barto via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>> On Jun 27, 2017, at 7:00 AM, mats petersson <mats at planetcatfish.com <mailto:mats at planetcatfish.com>> wrote:
>> 
>> Does it actually lock up, or just take a very long time. LLVM does have problems with very large functions, which leads to long times for "instruction selection" (worse in debug builds of the compiler too)
>> 
>> The same applies to g++ - I had something that was about 100k lines that took over 15 minutes to compile a while back - tweaking the options changed it to about 20s. Just because one compiler is "good" and the other "bad" doesn't mean that the "bad" one is broken, it's all depending on what the code looks like, one may well run through the compilation quickly, and the other take very long - "The devil is in the detail". In my g++ case, it was "dead store elimination, that took a long time, and on a file that is several megabytes, the difference with DSE enabled was a few kilobytes - from what I can tell [without looking at the code], g++ does DSE in O(n^2) time, by something akin to `for_each(instructions) { for_each(instructions) check_this_instruction(); }`
>> 
>> --
>> Mats
>> 
> 
> This was left running overnight. It was completely locked and wasn’t making any progress.
> 
> Just scraping the compile line from the PS output and pasting it into a shell has the compiler running in about 5-8 seconds. So something about running this through my compile daemon did something weird.
> 
> It doesn’t happen on the same file every time. If I delete the code cache and re-run my system again, it will pick another file to lock up on, or possibly run to completion without locking up. It appears random.
> 
> 
> 
> If you attach to clang with a debugger after it stalls, what code is it executing (or if MacOS has something like strace can you run that)?  Does that `ps` output you've shown indicate that the process is in the 'sleeping' state?
> 
> You've identified the environment as a contributor I think it makes sense to continue bisecting differences between the good and bad.  IIRC RLIMIT_AS limits the effective virtual address space of a process and not its resident memory.  On a good/baseline compile, how big does the address space get?  This seems like the most likely part to examine more closely.
> 
> 

David Barto
barto at cambridgesemantics.com

Sometimes, my best code does nothing. Most of the rest of it has bugs.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170628/78a9a2a2/attachment.html>