<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 - ORC is currently failing to deregister the EH-frame section when the JIT is torn down"
href="https://bugs.llvm.org/show_bug.cgi?id=32901">32901</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>ORC is currently failing to deregister the EH-frame section when the JIT is torn down
</td>
</tr>
<tr>
<th>Product</th>
<td>libraries
</td>
</tr>
<tr>
<th>Version</th>
<td>trunk
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Linux
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>enhancement
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>OrcJIT
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>dlurton@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>llvm-bugs@lists.llvm.org
</td>
</tr></table>
<p>
<div>
<pre>Created <span class=""><a href="attachment.cgi?id=18395" name="attach_18395" title="The reproduction case.">attachment 18395</a> <a href="attachment.cgi?id=18395&action=edit" title="The reproduction case.">[details]</a></span>
The reproduction case.
I have a reproduction case (below) where if I throw an exception before I call
JITSymbol::getAddress() everything works properly but throwing the same
exception afterward will result in a SIGSEGV during stack unwinding. Lang
Hames said on the llvm-dev mailing list:
"I've continued to dig in to this in my spare time and I've found the issue.
It's a use-after-free, rather than any sort of memory smashing. ORC is
currently failing to deregister the EH-frame section when the JIT is torn down
(but *is* deallocating the memory for it). Normally that's not disastrous
(though it does leave bogus EH frames in memory), but in your case the thrown
exception tears down the JIT itself, so the unwinder ends up reading eh-frames
that have been deallocated. I'm working on a fix to have the JIT properly
deregister EH frames, but one workaround for now would be to make sure you
catch the exception before it causes the JIT stack to be destructed."
This problem was initially discovered while working on my own project. While
troubleshooting this I've discvoered that when LLVM
is-DLLVM_USE_SANITIZER:STRING=Address the problem happens at different points
during execution, perhaps having something to do with the padding around the
stack variables added by the sanitizer? See the note after the call to
runTest() in main().
I'm running this under an up-to-date Antergos Linux, clang version: 3.9.1
(tried compiling LLVM and the example program below with gcc 6.3.1 and the
result is the same) clang set to default compiler by setting the following
environment variables:
CC=/usr/bin/clang
CXX=/usr/bin/clang++
Commands used to build LLVM:
git clone <a href="https://github.com/llvm-mirror/llvm.git">https://github.com/llvm-mirror/llvm.git</a>
git checkout release_40
cd llvm
mkdir build
cd build
cmake .. -DLLVM_BUILD_LLVM_DYLIB:BOOL=ON -DLLVM_ENABLE_RTTI:BOOL=ON
-DLLVM_ENABLE_EH:BOOL=ON -DLLVM_USE_SANITIZER:STRING=Address
-DLLVM_PARALLEL_COMPILE_JOBS:STRING=8 -DLLVM_ENABLE_ASSERTIONS:BOOL=ON
cmake --build . -- -j 8
sudo cmake --build . --target install
Command used to build test case executable:
clang test.cpp -std=c++14 -lstdc++ -lLLVM-4.0 -Wall -pedantic -Wextra
-fstack-protector-all -fsanitize=address -fexceptions
Then of course:
./a.out
Output from a.out:
ASAN:DEADLYSIGNAL
=================================================================
==6582==ERROR: AddressSanitizer: SEGV on unknown address 0x7f59eeb06020 (pc
0x7f59f1b20930 bp 0x000000000001 sp 0x7ffc5e546218 T0)
==6582==The signal is caused by a READ memory access.
The result if running `backtrace` in GDB while execution is paused after the
SIGSEGV occurs:
#0 read_encoded_value_with_base (encoding=encoding@entry=28 '\034',
base=base@entry=0, p=p@entry=0x7fffe8a06020 <error: Cannot access memory at
address 0x7fffe8a06020>, val=val@entry=0x7fffffffd6d8) at
/build/gcc/src/gcc/libgcc/unwind-pe.h:252
#1 0x00007fffeba05a61 in binary_search_single_encoding_fdes (pc=0x7fffeba04426
<_Unwind_Resume+54>, ob=0x0) at /build/gcc/src/gcc/libgcc/unwind-dw2-fde.c:908
#2 search_object (ob=ob@entry=0x60400001d9d0, pc=pc@entry=0x7fffeba04426
<_Unwind_Resume+54>) at /build/gcc/src/gcc/libgcc/unwind-dw2-fde.c:977
#3 0x00007fffeba05fdd in _Unwind_Find_registered_FDE (bases=0x7fffffffda78,
pc=0x7fffeba04426 <_Unwind_Resume+54>) at
/build/gcc/src/gcc/libgcc/unwind-dw2-fde.c:1013
#4 _Unwind_Find_FDE (pc=0x7fffeba04426 <_Unwind_Resume+54>,
bases=bases@entry=0x7fffffffda78) at
/build/gcc/src/gcc/libgcc/unwind-dw2-fde-dip.c:454
#5 0x00007fffeba02b23 in uw_frame_state_for
(context=context@entry=0x7fffffffd9d0, fs=fs@entry=0x7fffffffd820) at
/build/gcc/src/gcc/libgcc/unwind-dw2.c:1241
#6 0x00007fffeba03d40 in uw_init_context_1
(context=context@entry=0x7fffffffd9d0,
outer_cfa=outer_cfa@entry=0x7fffffffdc00, outer_ra=0x5110fc) at
/build/gcc/src/gcc/libgcc/unwind-dw2.c:1562
#7 0x00007fffeba04427 in _Unwind_Resume (exc=0x60d00000c7b0) at
/build/gcc/src/gcc/libgcc/unwind.inc:224
#8 0x00000000005110fc in runTest () at
/home/dave/projects/untitled/test.cpp:124
#9 0x0000000000511138 in main (argc=1, argv=0x7fffffffe698) at
/home/dave/projects/untitled/test.cpp:132
My test-case is attached. In runTest(), note the commented out throw statement
before symbol.getAddress() and the uncommented one after it. Also note the
comments after the call to runTest() in main().</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>