<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">This the the stack trace when the compiler locked up.</div><div class="">I attached with ‘lldb -p <pid>”</div><div class="">I did the thread backtrace all then a process resume</div><div class="">I interrupted the program again and did a second thread backtrace all. Both were identical.</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>David</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-family: 'PT Mono';" class=""><span style="font-variant-ligatures: no-common-ligatures; color: #a9a9a9" class="">(lldb) </span>thread backtrace all</div><div style="margin: 0px; font-family: 'PT Mono';" class="">* thread #1: tid = 0x13b475b, 0x00007fff90ec65da libsystem_kernel.dylib`syscall_thread_switch + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> * frame #0: 0x00007fff90ec65da libsystem_kernel.dylib`syscall_thread_switch + 10</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #1: 0x00007fff9497682d libsystem_platform.dylib`_OSSpinLockLockSlow + 63</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #2: 0x00007fff8ca7271b libsystem_malloc.dylib`szone_malloc_should_clear + 116</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #3: 0x00007fff8ca72667 libsystem_malloc.dylib`malloc_zone_malloc + 71</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #4: 0x00007fff8ca71187 libsystem_malloc.dylib`malloc + 42</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #5: 0x00007fff991fa43e libc++.1.dylib`operator new(unsigned long) + 30</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> 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</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #7: 0x000000010e6fc7a9 libLLVM.dylib`llvm::sys::findProgramByName(llvm::StringRef, llvm::ArrayRef<llvm::StringRef>) + 670</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #8: 0x000000010e6fd22c libLLVM.dylib`printSymbolizedStackTrace(llvm::StringRef, void**, int, llvm::raw_ostream&) + 186</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #9: 0x000000010e6fda7b libLLVM.dylib`llvm::sys::PrintStackTrace(llvm::raw_ostream&) + 93</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #10: 0x000000010e6fd116 libLLVM.dylib`llvm::sys::RunSignalHandlers() + 83</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #11: 0x000000010e6fde4d libLLVM.dylib`SignalHandler(int) + 183</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #12: 0x00007fff94977f1a libsystem_platform.dylib`_sigtramp + 26</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #13: 0x00007fff8ca757da libsystem_malloc.dylib`szone_free_definite_size + 4827</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> 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</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> 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</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> 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</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #17: 0x000000010eb894e0 libLLVM.dylib`llvm::recognizeBSwapOrBitReverseIdiom(llvm::Instruction*, bool, bool, llvm::SmallVectorImpl<llvm::Instruction*>&) + 1224</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #18: 0x000000010ec3f969 libLLVM.dylib`llvm::InstCombiner::MatchBSwap(llvm::BinaryOperator&) + 391</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #19: 0x000000010ec3fe7c libLLVM.dylib`llvm::InstCombiner::visitOr(llvm::BinaryOperator&) + 636</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #20: 0x000000010ec2e3a3 libLLVM.dylib`llvm::InstCombiner::run() + 1261</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #21: 0x000000010ec2f05c libLLVM.dylib`combineInstructionsOverFunction(llvm::Function&, llvm::InstCombineWorklist&, llvm::AAResults*, llvm::AssumptionCache&, llvm::TargetLibraryInfo&, llvm::DominatorTree&, bool, llvm::LoopInfo*) + 2431</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #22: 0x000000010ec2f2d7 libLLVM.dylib`llvm::InstructionCombiningPass::runOnFunction(llvm::Function&) + 297</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #23: 0x000000010e78e1ba libLLVM.dylib`llvm::FPPassManager::runOnFunction(llvm::Function&) + 290</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #24: 0x000000010ee59722 libLLVM.dylib`(anonymous namespace)::CGPassManager::runOnModule(llvm::Module&) + 810</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #25: 0x000000010e78e6be libLLVM.dylib`llvm::legacy::PassManagerImpl::run(llvm::Module&) + 606</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> 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</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #27: 0x000000010d38e53d clang`clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 1035</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #28: 0x000000010d693f59 clang`clang::ParseAST(clang::Sema&, bool, bool) + 374</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #29: 0x000000010d4fa5bd clang`clang::FrontendAction::Execute() + 69</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #30: 0x000000010d4c89d0 clang`clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 722</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #31: 0x000000010d526144 clang`clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1976</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #32: 0x000000010d205d96 clang`cc1_main(llvm::ArrayRef<char const*>, char const*, void*) + 1371</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #33: 0x000000010d20503e clang`main + 8255</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #34: 0x00007fff979fb5c9 libdyld.dylib`start + 1</div><div style="margin: 0px; font-family: 'PT Mono';" class=""> frame #35: 0x00007fff979fb5c9 libdyld.dylib`start + 1</div><div style="margin: 0px; font-family: 'PT Mono'; color: rgb(169, 169, 169);" class="">(lldb) </div></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Jun 27, 2017, at 7:20 AM, Brian Cain <<a href="mailto:brian.cain@gmail.com" class="">brian.cain@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, Jun 27, 2017 at 9:09 AM, David Barto via cfe-dev <span dir="ltr" class=""><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class=""><span class="gmail-"><blockquote type="cite" class=""><div class="">On Jun 27, 2017, at 7:00 AM, mats petersson <<a href="mailto:mats@planetcatfish.com" target="_blank" class="">mats@planetcatfish.com</a>> wrote:</div><br class="gmail-m_-8584712459310043789Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div class="">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)<br class=""><br class=""> 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(); }`<br class=""><br class="">--<br class=""></div>Mats<br class=""></div><div class="gmail_extra"><br class=""></div></div></blockquote><br class=""></span>This was left running overnight. It was completely locked and wasn’t making any progress.<div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><span class="gmail-HOEnZb"><font color="#888888" class=""><div class=""><br class=""></div></font></span></div></div></div></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class="">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?</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class=""><br class=""></div></div>
</div></div>
</div></blockquote></div><br class=""><div apple-content-edited="true" class="">
<div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">David Barto<br class=""><a href="mailto:barto@cambridgesemantics.com" class="">barto@cambridgesemantics.com</a></div><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""></div><div style="color: rgb(0, 0, 0); letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Sometimes, my best code does nothing. Most of the rest of it has bugs.<br class=""><br class=""><br class=""></div></div>
</div>
<br class=""></body></html>