[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