<div dir="rtl"><div dir="ltr">Hi,</div><div dir="ltr"><br></div><div dir="ltr">I had similar problems with EH in ELF in RTDyldMemoryManager::registerEHFrames() calling __register_frame().</div><div dir="ltr"><br></div><div dir="ltr">

I'm not sure these problems are related to this problem since your crash happens in  RuntimeDyldMachO::registerEHFrames() in its own processFDE (there are two functions named processFDE(), one in RuntimeDyldMachO.cpp and one in RTDyldMemoryManager.cpp)  <u>before</u> RTDyldMemoryManager::registerEHFrames() and __register_frame() are called.</div>

<div dir="ltr"><br></div><div dir="ltr">It would seem that even if  RTDyldMemoryManager::registerEHFrames() and __register_frame() got problematic input (as with the ELF dyn. linker) it should not cause a crash in the calling code but either a malfunction of exceptions or crash in RTDyldMemoryManager::registerEHFrames() / __register_frame(). A crash like the one you see should be related to RuntimeDyldMachO::registerEHFrames() inputs only.</div>

<div dir="ltr"><br></div><div dir="ltr">Yaron<br></div><div dir="ltr"><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote"><div dir="ltr">2013/10/14 Kaylor, Andrew <span dir="ltr"><<a href="mailto:andrew.kaylor@intel.com" target="_blank">andrew.kaylor@intel.com</a>></span></div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Christian,<br>
<br>
Thanks for sharing this.<br>
<br>
Yaron Keren has been investigating some problems in the EH frame registration code recently, and I think this may be related.  It at least sounds similar to the type of variations in behavior based on code size that Yaron was seeing.<br>


<br>
-Andy<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:llvmdev-bounces@cs.uiuc.edu">llvmdev-bounces@cs.uiuc.edu</a> [mailto:<a href="mailto:llvmdev-bounces@cs.uiuc.edu">llvmdev-bounces@cs.uiuc.edu</a>] On Behalf Of Christian Schafmeister<br>
Sent: Sunday, October 13, 2013 10:52 PM<br>
To: <a href="mailto:llvmdev@cs.uiuc.edu">llvmdev@cs.uiuc.edu</a><br>
Subject: [LLVMdev] A weird, reproducable problem with MCJIT<br>
<br>
<br>
I switched my Common Lisp compiler to use MCJIT on the weekend and ran into a weird problem compiling one particular function.<br>
<br>
It crashes with an EXC_BAD_ACCESS error in MCJIT::finalizeObject when calling processFDE.<br>
<br>
The weird part is that the function does not appear to do anything special and I've whittled it down to the minimum size that still causes the crash. If I remove even one statement it compiles fine.  Note: The function doesn't make much sense anymore but it does compile fine.<br>


It does have a lot of nested scopes.<br>
<br>
I can single step through processFDE and I see it pulls up a Length in processFDE of 1 and then a length of 16#1000000  - clearly something has been corrupted.<br>
<br>
Here is the top of the backtrace from lldb:<br>
----------------------<br>
* thread #1: tid = 0x557509, 0x0000000107e6e066 libLLVM-3.4svn.dylib`llvm::processFDE(unsigned char*, long, long) + 134 at /Users/meister/Development/cando/brcl/externals/src/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldMachO.cpp:35, stop reason = EXC_BAD_ACCESS (code=2, address=0x1102adad1)<br>


    frame #0: 0x0000000107e6e066 libLLVM-3.4svn.dylib`llvm::processFDE(unsigned char*, long, long) + 134 at /Users/meister/Development/cando/brcl/externals/src/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldMachO.cpp:35<br>


    frame #1: 0x0000000107e6df04 libLLVM-3.4svn.dylib`llvm::RuntimeDyldMachO::registerEHFrames() + 356 at /Users/meister/Development/cando/brcl/externals/src/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyldMachO.cpp:81<br>


    frame #2: 0x0000000107e36f39 libLLVM-3.4svn.dylib`llvm::RuntimeDyld::registerEHFrames() + 25 at /Users/meister/Development/cando/brcl/externals/src/llvm/lib/ExecutionEngine/RuntimeDyld/RuntimeDyld.cpp:595<br>
    frame #3: 0x0000000107aca9c7 libLLVM-3.4svn.dylib`llvm::MCJIT::finalizeObject() + 775 at /Users/meister/Development/cando/brcl/externals/src/llvm/lib/ExecutionEngine/MCJIT/MCJIT.cpp:226<br>
    frame #4: 0x0000000103da55d3 libllvmo_dbg.dylib`llvmo::ExecutionEngine_O::getCompiledFunction(mem::smart_ptr<core::Symbol_O>, mem::smart_ptr<llvmo::Function_O>, mem::smart_ptr<core::ActivationFrame_O>, mem::smart_ptr<core::Symbol_O>) + 115 at /Users/meister/Development/cando/brcl/src/llvmo/../../src/llvmo/llvmoExpose.cc:811<br>


<br>
<br>
Here is the function that causes the crash (it's Common Lisp and all macros have been expanded).<br>
<br>
(defun match-dimensions (array pat)<br>
  (let ((zzz (eq pat '*)))<br>
    (if zzz<br>
        zzz<br>
        (let ((rank (array-rank array) ))<br>
          (if (listp pat)<br>
              (BLOCK NIL<br>
                (LET* (<br>
                       (%DOTIMES-VAR 100)<br>
                       (I 0)<br>
                       )<br>
                  (TAGBODY<br>
                     (GO bot)<br>
                   top<br>
                     (if (not t) (progn))<br>
                     (SETQ PAT (CDR PAT))<br>
                     (SETQ I (1+ I))<br>
                   bot<br>
                     (if (< I %DOTIMES-VAR) (GO top))<br>
                     )<br>
                  (NULL PAT))))))))<br>
<br>
<br>
<br>
The LLVM-IR file generated by compiling this function definition is<br>
here: <a href="https://dl.dropboxusercontent.com/u/6229900/broken.ll" target="_blank">https://dl.dropboxusercontent.com/u/6229900/broken.ll</a><br>
<br>
Any suggestions or pointers on how to debug this are welcome.<br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a>         <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br></div>