Yuri
2011-Mar-31 19:59 UTC
[LLVMdev] Unallocated address error triggered from ::RALinScan::assignRegOrStackSlotAtInterval on i386
I am debugging the memory issue that manifests itself like this: *** glibc detected *** ../app/app.OWS: free(): invalid pointer: 0x0ad391fc *** ======= Backtrace: ========/lib/libc.so.6(+0x6c501)[0x4f6501] /lib/libc.so.6(+0x6dd70)[0x4f7d70] /lib/libc.so.6(cfree+0x6d)[0x4fae5d] ../app/app.OWS(_ZNSt8_Rb_treeIjjSt9_IdentityIjESt4lessIjESaIjEE5eraseESt17_Rb_tree_iteratorIjES7_+0x4b)[0x83de6eb] /usr/local/llvm/svn-r128446/lib/libLLVM-3.0svn.so(+0x63db58)[0x1619b58] ======= Memory map: =======00110000-00116000 r-xp 00000000 08:01 143119 /lib/libnss_compat-2.12.1.so 00116000-00117000 r--p 00006000 08:01 143119 /lib/libnss_compat-2.12.1.so 00117000-00118000 rw-p 00007000 08:01 143119 /lib/libnss_compat-2.12.1.so 00118000-00121000 r-xp 00000000 08:01 143794 /lib/libnss_nis-2.12.1.so 00121000-00122000 r--p 00008000 08:01 143794 /lib/libnss_nis-2.12.1.so 00122000-00123000 rw-p 00009000 08:01 143794 /lib/libnss_nis-2.12.1.so 00188000-00267000 r-xp 00000000 08:01 264760 /usr/lib/libstdc++.so.6.0.14 00267000-0026b000 r--p 000de000 08:01 264760 /usr/lib/libstdc++.so.6.0.14 0026b000-0026c000 rw-p 000e2000 08:01 264760 /usr/lib/libstdc++.so.6.0.14 <...skipped...> 0048a000-005e1000 r-xp 00000000 08:01 143094 /lib/libc-2.12.1.so 005e1000-005e3000 r--p 00157000 08:01 143094 /lib/libc-2.12.1.so 005e3000-005e4000 rw-p 00159000 08:01 143094 /lib/libc-2.12.1.so <...skipped...> b769b000-b789b000 r--p 00000000 08:01 260676 /usr/lib/locale/locale-archive b789b000-b789f000 rw-p 00000000 00:00 0 b78ad000-b78ae000 r--p 002a1000 08:01 260676 /usr/lib/locale/locale-archive b78ae000-b78b1000 rw-p 00000000 00:00 0 bfb85000-bfba6000 rw-p 00000000 00:00 0 [stack] Stack dump: 0. Running pass 'Linear Scan Register Allocator' on function '@my_function_0001' When I am printing all allocations/deallocations I see that this address has indeed never been allocated. Stack trace during this error message is: #0 0x0012e416 in __kernel_vsyscall () #1 0x002ab941 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #2 0x002aee42 in abort () at abort.c:92 #3 0x002e3305 in __libc_message (do_abort=2, fmt=0x3bb280 "*** glibc detected *** %s: %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:189 #4 0x002ed501 in malloc_printerr (action=<value optimized out>, str=0x6<Address 0x6 out of bounds>, ptr=0x92461fc) at malloc.c:6283 #5 0x002eed70 in _int_free (av=<value optimized out>, p=<value optimized out>) at malloc.c:4795 #6 0x002f1e5d in __libc_free (mem=0x92461fc) at malloc.c:3738 #7 0x083de6eb in xfree (this=0xa6bd3f8, __first=..., __last=...) at ../common/allocator.h:52 #8 operator delete (this=0xa6bd3f8, __first=..., __last=...) at ../common/allocator.h:72 #9 deallocate (this=0xa6bd3f8, __first=..., __last=...) at /usr/local/gcc/4.5.2/lib/gcc/i686-pc-linux-gnu/4.5.2/../../../../include/c++/4.5.2/ext/new_allocator.h:95 #10 _M_put_node (this=0xa6bd3f8, __first=..., __last=...) at /usr/local/gcc/4.5.2/lib/gcc/i686-pc-linux-gnu/4.5.2/../../../../include/c++/4.5.2/bits/stl_tree.h:363 #11 _M_destroy_node (this=0xa6bd3f8, __first=..., __last=...) at /usr/local/gcc/4.5.2/lib/gcc/i686-pc-linux-gnu/4.5.2/../../../../include/c++/4.5.2/bits/stl_tree.h:409 #12 erase (this=0xa6bd3f8, __first=..., __last=...) at /usr/local/gcc/4.5.2/lib/gcc/i686-pc-linux-gnu/4.5.2/../../../../include/c++/4.5.2/bits/stl_tree.h:1367 #13 std::_Rb_tree<unsigned int, unsigned int, std::_Identity<unsigned int>, std::less<unsigned int>, std::allocator<unsigned int> >::erase (this=0xa6bd3f8, __first=..., __last=...) at /usr/local/gcc/4.5.2/lib/gcc/i686-pc-linux-gnu/4.5.2/../../../../include/c++/4.5.2/bits/stl_tree.h:1449 #14 0x00b52b58 in (anonymous namespace)::RALinScan::assignRegOrStackSlotAtInterval(llvm::LiveInterval*) () from /usr/local/llvm/svn-r128446/lib/libLLVM-3.0svn.so #15 0x0169dc00 in llvm::X86::GR32RegClass () from /usr/local/llvm/svn-r128446/lib/libLLVM-3.0svn.so Problem occurs when I am attempting to run a large module in JIT, from ExecutionEngine::runFunction, after static constructors have succeeded. EngineKind=1, OptLevel=3. When I change OptLevel to 0 problem disappears. llvm::NoFramePointerElim is true. When I change this to false problem disappears. I can't supply the whole module in a test case, it depends on many external functions and contains a lot of irrelevant information. My question is somewhat vague. Can anyone identify the problem by just looking at the code in and around this function? Someone must be placing unallocated address in STL map. On the other hand, how can I run just this single function through those methods that cause the problem: ::RALinScan::assignRegOrStackSlotAtInterval ? Can I still do this with the broken dependencies so that I can create a test case? Linux ubuntu 2.6.35-28-generic #49-Ubuntu SMP i686 GNU/Linux Yuri -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110331/2afa864a/attachment.html>
Duncan Sands
2011-Apr-01 02:48 UTC
[LLVMdev] Unallocated address error triggered from ::RALinScan::assignRegOrStackSlotAtInterval on i386
Hi Yuri,> I am debugging the memory issue that manifests itself like this: > > *** glibc detected *** ../app/app.OWS: free(): invalid pointer: 0x0ad391fc ***try running under valgrind. Note that if the program being JIT'd corrupts memory then this can cause the JIT itself to blow up. Ciao, Duncan.
Yuri
2011-Apr-01 03:24 UTC
[LLVMdev] Unallocated address error triggered from ::RALinScan::assignRegOrStackSlotAtInterval on i386
On 03/31/2011 19:48, Duncan Sands wrote:> Hi Yuri, > > >> I am debugging the memory issue that manifests itself like this: >> >> *** glibc detected *** ../app/app.OWS: free(): invalid pointer: 0x0ad391fc *** >> > try running under valgrind. Note that if the program being JIT'd corrupts > memory then this can cause the JIT itself to blow upWill try valgrind. It doesn't look like the program started running at the moment of failure, besides static constructors that are very simple and can't corrupt memory. Also DisableLazyCompilation is set. That should force all compiles be done before the run. Yuri
Maybe Matching Threads
- [LLVMdev] Unallocated address error triggered from ::RALinScan::assignRegOrStackSlotAtInterval on i386
- [LLVMdev] Folding instructions
- [LLVMdev] Crash in llvm::JITDwarfEmitter::EmitDwarfTable on 2.8 and 2.9 release but not on trunk?
- [LLVMdev] Crash in llvm::JITDwarfEmitter::EmitDwarfTable on 2.8 and 2.9 release but not on trunk?
- Compilation problem - CentOS 4.2 - x86_64