Created attachment 10516 [details] The crashing input $ ~/llvm/fresh-build/bin/llc --version LLVM (http://llvm.org/): LLVM version 3.4svn DEBUG build with assertions. Built May 14 2013 (00:28:00). Default target: x86_64-unknown-linux-gnu Host CPU: corei7-avx Registered Targets: aarch64 - AArch64 arm - ARM cpp - C++ backend hexagon - Hexagon mblaze - MBlaze mips - Mips mips64 - Mips64 [experimental] mips64el - Mips64el [experimental] mipsel - Mipsel msp430 - MSP430 [experimental] nvptx - NVIDIA PTX 32-bit nvptx64 - NVIDIA PTX 64-bit ppc32 - PowerPC 32 ppc64 - PowerPC 64 sparc - Sparc sparcv9 - Sparc V9 systemz - SystemZ thumb - Thumb x86 - 32-bit X86: Pentium-Pro and above x86-64 - 64-bit X86: EM64T and AMD64 xcore - XCore $ ~/llvm/fresh-build/bin/llc /var/tmp/a.ll While deleting: metadata % An asserting value handle still pointed to this value! UNREACHABLE executed at /home/majnemer/llvm/fresh-src/lib/IR/Value.cpp:633! 0 llc 0x00000000012122da 1 llc 0x0000000001212561 2 llc 0x0000000001211fb0 3 libpthread.so.0 0x00007f0e9358bcb0 4 libc.so.6 0x00007f0e929e1425 gsignal + 53 5 libc.so.6 0x00007f0e929e4b8b abort + 379 6 llc 0x00000000011d2d58 7 llc 0x00000000011290e5 8 llc 0x000000000112766a 9 llc 0x00000000010fb78e 10 llc 0x00000000010fba07 11 llc 0x00000000010f0313 12 llc 0x00000000010eec21 13 llc 0x00000000010ef48f 14 llc 0x00000000011d65ff 15 llc 0x00000000011d662d 16 llc 0x000000000042c2c7 17 llc 0x0000000000427e4b 18 libc.so.6 0x00007f0e929cc76d __libc_start_main + 237 19 llc 0x0000000000427779 Stack dump: 0. Program arguments: /home/majnemer/llvm/fresh-build/bin/llc /var/tmp/a.ll zsh: abort (core dumped) ~/llvm/fresh-build/bin/llc /var/tmp/a.ll
Created attachment 10517 [details] bugpoint reduced input
Created attachment 10825 [details] reduced testcase The bug happens because the list of subprograms in the compile unit contains duplicates. !3 = metadata !{metadata !4, metadata !4} in my new testcase.
I too encountered this bug and could track it down to DwarfDebug::collectDeadVariables() where LexicalScope objects are created but not properly destroyed if the same sub-program is encountered more than once in the list. This is because new LexicalScope objects for the same sub-program replace existing ones in the DeadFnScopeMap which seems to be responsible for destroying the LexicalScope objects at the end of the function. Consequently, in some rare cases, LexicalScope objects leak and the AssertingVH's they contain trigger an assertion in the LLVMContextImpl destructor (at least that's where the assertions happen in my case). A simple fix would be to just 'continue' if the sub-program already is a key in the DeadFnScopeMap. But I don't know enough to tell whether the duplicates in the sub-programs list point to a deeper, underlying issue. Another interesting bit of information: The assertions are only triggered when generating optimized programs, so (again, at least in my case) the duplicates in the list probably only get introduced by some optimization pass.
Hrm. Sadly the IR isn't valid anymore, but we definitely shouldn't have duplicates put into the subprograms array.
It's definitely the duplicates in the list that cause the memory leak. Letting the function handle the duplicate entries validly would be an easy fix. If not that, an assertion at this point would still be a lot better than so much later in ~LLVMContextImpl() where it is hard to tell what the real problem is.
I'd rather fix the problem of duplicate entries, see my change of earlier in the week that asserts if we run that twice on the same metadata.
Can the issue be fixed this way? Because (if I understand it correctly) the subprograms list is just a wrapper around the actual metadata nodes, which could mean that some invalid IR (like I seem to produce at the moment ;) could still result in duplicates in the list and consequently a very subtle memory leak issue. So this could be seen as a problem of handling possibly invalid user input instead of a merely internal violation of a method's preconditions. But you know the code better than me and I'm confident that you'll fix it the right way :) My main concern is that the memory leak is replaced by something that causes less trouble. Thank you, by the way, for the quick response to the report!
I don't like invalid for this, but after the changes to the metadata I can't load the .ll files anymore. If we run into it again we can reopen it.