[llvm-commits] [llvm] r99400 - in /llvm/trunk: lib/CodeGen/LiveIntervalAnalysis.cpp test/CodeGen/Generic/2010-03-24-liveintervalleak.ll

Bob Wilson bob.wilson at apple.com
Wed Mar 24 14:22:23 PDT 2010


On Mar 24, 2010, at 1:58 PM, Török Edwin wrote:

> On 03/24/2010 10:24 PM, Bob Wilson wrote:
> 
> Could you give me some more details on which configuration this breaks?
> Did it happen when running the test-suite with llvm-gcc or clang?
> Did llc crash, or did valgrind show an error?

I was afraid you were going to ask that....  Oh well, it's good for me to figure out how these things work!  I poked around on the buildbot and found the error.  llc crashed with the following:

llc(1164) malloc: *** error for object 0x1041219c0: pointer being freed was not allocated
*** set a breakpoint in malloc_error_break to debug
0  llc               0x00000001008fd932 PrintStackTrace(void*) + 34
1  llc               0x00000001008fe11e SignalHandler(int) + 622
2  libSystem.B.dylib 0x00007fff82898eaa _sigtramp + 26
3  libSystem.B.dylib 0x00007fff5fbfea98 _sigtramp + 3711327240
4  libSystem.B.dylib 0x00007fff8283f155 free + 128
5  llc               0x00000001005a1301 llvm::LiveIntervals::releaseMemory() + 161
6  llc               0x0000000100886635 llvm::PMDataManager::freePass(llvm::Pass*, llvm::StringRef, llvm::PassDebuggingString) + 117
7  llc               0x0000000100886bdc llvm::PMDataManager::removeDeadPasses(llvm::Pass*, llvm::StringRef, llvm::PassDebuggingString) + 172
8  llc               0x00000001008873c8 llvm::FPPassManager::runOnFunction(llvm::Function&) + 280
9  llc               0x00000001008876db llvm::FunctionPassManagerImpl::run(llvm::Function&) + 139
10 llc               0x0000000100887916 llvm::FunctionPassManager::run(llvm::Function&) + 102
11 llc               0x0000000100039d38 main + 3672
12 llc               0x00000001000385a8 start + 52
13 llc               0x0000000000000009 start + 4294736533

This was running with llvm-gcc.  I'd send you the bitcode file except that it has already been overwritten.  Is that good enough to help you figure it out?

> 
> If I apply my patch on top of llvm 2.7 I only get these unrelated
> invalid reads from valgrind (when running test-suite with clang)
> 
> ==6908== Memcheck, a memory error detector
> 
> ==6908== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
> 
> ==6908== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for
> copyright info
> ==6908== Command: /home/edwin/llvm2.7/llvm-2.7/Release/bin/llc
> -asm-verbose=false -O3 Output/clamscan.llvm.bc -o Output/clamscan.llc.s
> -info-output-file=/home/edwin/llvm2.7/llvm-2.7/projects/llvm-test/MultiSource/Applications/ClamAV/Output/clamscan.llc.s.info
> -stats -time-passes
> 
> ==6908==
> 
> ==6908== Invalid read of size 1
> 
> ==6908==    at 0x7A7A54: void
> std::__insertion_sort<llvm::StringRef*>(llvm::StringRef*,
> llvm::StringRef*) (in /home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)
> 
> 
> ==6908==    by 0x79225B:
> llvm::X86TargetLowering::ExpandInlineAsm(llvm::CallInst*) const (in
> /home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)
> 
> 
> ==6908==    by 0xA8BABD: (anonymous
> namespace)::CodeGenPrepare::runOnFunction(llvm::Function&) (in
> /home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)
> 
> 
> ==6908==    by 0xBFDBB5:
> llvm::FPPassManager::runOnFunction(llvm::Function&) (in
> /home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)
> ==6908==    by 0xBFDD90:
> llvm::FunctionPassManagerImpl::run(llvm::Function&) (in
> /home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)
> ==6908==    by 0xBFDFBD: llvm::FunctionPassManager::run(llvm::Function&)
> (in /home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)
> ==6908==    by 0x52A113: main (in
> /home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)
> 
> ==6908==  Address 0x7954db8 is 24 bytes inside a block of size 58 free'd
> 
> ==6908==    at 0x4A06ACE: operator delete(void*)
> (vg_replace_malloc.c:346)
> 
> ==6908==    by 0x3CD5AA8948: std::basic_string<char,
> std::char_traits<char>, std::allocator<char> >::~basic_string() (in
> /usr/lib/libstdc++.so.6.0.13)
> 
> ==6908==    by 0x79286A:
> llvm::X86TargetLowering::ExpandInlineAsm(llvm::CallInst*) const (in
> /home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)
> 
> 
> ==6908==    by 0xA8BABD: (anonymous
> namespace)::CodeGenPrepare::runOnFunction(llvm::Function&) (in
> /home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)
> 
> 
> ==6908==    by 0xBFDBB5:
> llvm::FPPassManager::runOnFunction(llvm::Function&) (in
> /home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)
> ==6908==    by 0xBFDD90:
> llvm::FunctionPassManagerImpl::run(llvm::Function&) (in
> /home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)
> ==6908==    by 0xBFDFBD: llvm::FunctionPassManager::run(llvm::Function&)
> (in /home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)
> ==6908==    by 0x52A113: main (in
> /home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)
> 
> ==6908==
> 
>> 
>> On Mar 24, 2010, at 6:50 AM, Torok Edwin wrote:
>> 
>>> Author: edwin
>>> Date: Wed Mar 24 08:50:36 2010
>>> New Revision: 99400
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=99400&view=rev
>>> Log:
>>> Fix memory leak in liveintervals: the destructor for VNInfos must be called,
>>> otherwise the SmallVector it contains doesn't free its memory.
>>> In most cases LiveIntervalAnalysis could get away by not calling the destructor,
>>> because VNInfos are bumpptr-allocated, and smallvectors usually don't grow.
>>> However when the SmallVector does grow it always leaks.
> 
> 
> Best regards,
> --Edwin
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20100324/ed71ca5d/attachment.html>


More information about the llvm-commits mailing list