<html>
<head>
<base href="https://bugs.llvm.org/">
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - setrlimit for Address space causes clang to lock up"
href="https://bugs.llvm.org/show_bug.cgi?id=33627">33627</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>setrlimit for Address space causes clang to lock up
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>4.0
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Macintosh
</td>
</tr>
<tr>
<th>OS</th>
<td>MacOS X
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>C++
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>barto@cambridgesemantics.com
</td>
</tr>
<tr>
<th>CC</th>
<td>dgregor@apple.com, llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>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</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>