[LLVMdev] A weird, reproducable problem with MCJIT

Kaylor, Andrew andrew.kaylor at intel.com
Mon Oct 14 10:18:53 PDT 2013


Hi Christian,

Thanks for sharing this.

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.

-Andy

-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Christian Schafmeister
Sent: Sunday, October 13, 2013 10:52 PM
To: llvmdev at cs.uiuc.edu
Subject: [LLVMdev] A weird, reproducable problem with MCJIT


I switched my Common Lisp compiler to use MCJIT on the weekend and ran into a weird problem compiling one particular function.

It crashes with an EXC_BAD_ACCESS error in MCJIT::finalizeObject when calling processFDE.

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.
It does have a lot of nested scopes.

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.
   
Here is the top of the backtrace from lldb:
----------------------
* 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)
    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
    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
    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
    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
    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


Here is the function that causes the crash (it's Common Lisp and all macros have been expanded).

(defun match-dimensions (array pat)
  (let ((zzz (eq pat '*)))
    (if zzz
	zzz
	(let ((rank (array-rank array) ))
	  (if (listp pat)
	      (BLOCK NIL
		(LET* (
		       (%DOTIMES-VAR 100)
		       (I 0)
		       )
		  (TAGBODY
		     (GO bot)
		   top
		     (if (not t) (progn))
		     (SETQ PAT (CDR PAT))
		     (SETQ I (1+ I))
		   bot
		     (if (< I %DOTIMES-VAR) (GO top))
		     ) 
		  (NULL PAT))))))))



The LLVM-IR file generated by compiling this function definition is
here: https://dl.dropboxusercontent.com/u/6229900/broken.ll

Any suggestions or pointers on how to debug this are welcome.

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev




More information about the llvm-dev mailing list