<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>On Mar 24, 2010, at 1:58 PM, Török Edwin wrote:</div><div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On 03/24/2010 10:24 PM, Bob Wilson wrote:<br><font class="Apple-style-span" color="#006312"><br></font>Could you give me some more details on which configuration this breaks?<br>Did it happen when running the test-suite with llvm-gcc or clang?<br>Did llc crash, or did valgrind show an error?<br></div></blockquote><div><br></div>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:</div><div><br></div><div><div>llc(1164) malloc: *** error for object 0x1041219c0: pointer being freed was not allocated</div><div>*** set a breakpoint in malloc_error_break to debug</div><div>0 llc 0x00000001008fd932 PrintStackTrace(void*) + 34</div><div>1 llc 0x00000001008fe11e SignalHandler(int) + 622</div><div>2 libSystem.B.dylib 0x00007fff82898eaa _sigtramp + 26</div><div>3 libSystem.B.dylib 0x00007fff5fbfea98 _sigtramp + 3711327240</div><div>4 libSystem.B.dylib 0x00007fff8283f155 free + 128</div><div>5 llc 0x00000001005a1301 llvm::LiveIntervals::releaseMemory() + 161</div><div>6 llc 0x0000000100886635 llvm::PMDataManager::freePass(llvm::Pass*, llvm::StringRef, llvm::PassDebuggingString) + 117</div><div>7 llc 0x0000000100886bdc llvm::PMDataManager::removeDeadPasses(llvm::Pass*, llvm::StringRef, llvm::PassDebuggingString) + 172</div><div>8 llc 0x00000001008873c8 llvm::FPPassManager::runOnFunction(llvm::Function&) + 280</div><div>9 llc 0x00000001008876db llvm::FunctionPassManagerImpl::run(llvm::Function&) + 139</div><div>10 llc 0x0000000100887916 llvm::FunctionPassManager::run(llvm::Function&) + 102</div><div>11 llc 0x0000000100039d38 main + 3672</div><div>12 llc 0x00000001000385a8 start + 52</div><div>13 llc 0x0000000000000009 start + 4294736533</div><div><br></div><div>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?</div><div><br></div><div></div><blockquote type="cite"><div><br>If I apply my patch on top of llvm 2.7 I only get these unrelated<br>invalid reads from valgrind (when running test-suite with clang)<br><br>==6908== Memcheck, a memory error detector<br><br>==6908== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.<br><br>==6908== Using Valgrind-3.5.0-Debian and LibVEX; rerun with -h for<br>copyright info<br>==6908== Command: /home/edwin/llvm2.7/llvm-2.7/Release/bin/llc<br>-asm-verbose=false -O3 Output/clamscan.llvm.bc -o Output/clamscan.llc.s<br>-info-output-file=/home/edwin/llvm2.7/llvm-2.7/projects/llvm-test/MultiSource/Applications/ClamAV/Output/clamscan.llc.s.info<br>-stats -time-passes<br><br>==6908==<br><br>==6908== Invalid read of size 1<br><br>==6908== at 0x7A7A54: void<br>std::__insertion_sort<llvm::StringRef*>(llvm::StringRef*,<br>llvm::StringRef*) (in /home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)<br><br><br>==6908== by 0x79225B:<br>llvm::X86TargetLowering::ExpandInlineAsm(llvm::CallInst*) const (in<br>/home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)<br><br><br>==6908== by 0xA8BABD: (anonymous<br>namespace)::CodeGenPrepare::runOnFunction(llvm::Function&) (in<br>/home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)<br><br><br>==6908== by 0xBFDBB5:<br>llvm::FPPassManager::runOnFunction(llvm::Function&) (in<br>/home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)<br>==6908== by 0xBFDD90:<br>llvm::FunctionPassManagerImpl::run(llvm::Function&) (in<br>/home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)<br>==6908== by 0xBFDFBD: llvm::FunctionPassManager::run(llvm::Function&)<br>(in /home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)<br>==6908== by 0x52A113: main (in<br>/home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)<br><br>==6908== Address 0x7954db8 is 24 bytes inside a block of size 58 free'd<br><br>==6908== at 0x4A06ACE: operator delete(void*)<br>(vg_replace_malloc.c:346)<br><br>==6908== by 0x3CD5AA8948: std::basic_string<char,<br>std::char_traits<char>, std::allocator<char> >::~basic_string() (in<br>/usr/lib/libstdc++.so.6.0.13)<br><br>==6908== by 0x79286A:<br>llvm::X86TargetLowering::ExpandInlineAsm(llvm::CallInst*) const (in<br>/home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)<br><br><br>==6908== by 0xA8BABD: (anonymous<br>namespace)::CodeGenPrepare::runOnFunction(llvm::Function&) (in<br>/home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)<br><br><br>==6908== by 0xBFDBB5:<br>llvm::FPPassManager::runOnFunction(llvm::Function&) (in<br>/home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)<br>==6908== by 0xBFDD90:<br>llvm::FunctionPassManagerImpl::run(llvm::Function&) (in<br>/home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)<br>==6908== by 0xBFDFBD: llvm::FunctionPassManager::run(llvm::Function&)<br>(in /home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)<br>==6908== by 0x52A113: main (in<br>/home/edwin/llvm2.7/llvm-2.7/Release/bin/llc)<br><br>==6908==<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite">On Mar 24, 2010, at 6:50 AM, Torok Edwin wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">Author: edwin<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Date: Wed Mar 24 08:50:36 2010<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">New Revision: 99400<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">URL: <a href="http://llvm.org/viewvc/llvm-project?rev=99400&view=rev">http://llvm.org/viewvc/llvm-project?rev=99400&view=rev</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Log:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">Fix memory leak in liveintervals: the destructor for VNInfos must be called,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">otherwise the SmallVector it contains doesn't free its memory.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">In most cases LiveIntervalAnalysis could get away by not calling the destructor,<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">because VNInfos are bumpptr-allocated, and smallvectors usually don't grow.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">However when the SmallVector does grow it always leaks.<br></blockquote></blockquote><br><br>Best regards,<br>--Edwin<br><br></div></blockquote></div><br></body></html>