[llvm-bugs] [Bug 33627] New: setrlimit for Address space causes clang to lock up

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Jun 28 10:24:08 PDT 2017


https://bugs.llvm.org/show_bug.cgi?id=33627

            Bug ID: 33627
           Summary: setrlimit for Address space causes clang to lock up
           Product: clang
           Version: 4.0
          Hardware: Macintosh
                OS: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: barto at cambridgesemantics.com
                CC: dgregor at apple.com, llvm-bugs at lists.llvm.org

Our company develops an in-memory database and we limit the CPU time and Memory
that the compiler is allowed to use. When we start the compiler we fork and
then call setrlimit as follows:

      // set limits on time and space if we are doing an optimized compile
      struct rlimit rlim;
      rlim.rlim_cur = rlim.rlim_max = m_compile_max_seconds;     // typically
30 seconds

      if (0 != setrlimit(RLIMIT_CPU, &rlim))
      {
        xthrow(Sys_rlimit, errno, "system", "can't bound compilation time");
      }

      rlim.rlim_cur = rlim.rlim_max = m_compile_max_memory * (1 << 20);   //
typically 500MB

      if (0 != setrlimit(RLIMIT_AS, &rlim))
      {
        xthrow(Sys_rlimit, errno, "system", "can't limit compiler memory
usage");
      }

When clang is run with these limits it locks up when it exceeds the memory
limit with the following stack trace. At this point clang will fail to exit or
return to the user in any way.

(Note the recursive entry to libsystem_malloc, and the attempt to allocate
space in the signal handler, something that isn't signal safe.)

(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

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170628/029b067f/attachment-0001.html>


More information about the llvm-bugs mailing list