[llvm] r297971 - Salvage debug info from instructions about to be deleted

Thu Mar 16 14:26:46 PDT 2017

I recommitted in r297994 with the bug fixed. Many thanks for the test case!

-- adrian
> On Mar 16, 2017, at 1:26 PM, Evgenii Stepanov <eugeni.stepanov at gmail.com> wrote:
> 
> ulimit -v 2000000
> bin/clang-5.0  -target x86_64-unknown-linux-gnu -c -g     -O2  -std=c++11 1.ii
> 
> Test case attached.
> 
> terminate called after throwing an instance of 'std::bad_alloc'
>  what():  std::bad_alloc
> 
> 
> On Thu, Mar 16, 2017 at 1:19 PM, Yung, Douglas <douglas.yung at sony.com> wrote:
>> Our internal bot also hit something around this change, I suspect it is the same thing, I'm trying to get a reproducible. FWIW, here is the console output from the failed build:
>> 
>> FAILED: cd /home/siadmin/jenkins/w/opensource/opensource_build/build/projects/compiler-rt/lib/tsan/tests/unit && /home/siadmin/jenkins/w/opensource/opensource_build/build/./bin/clang -fPIC -fvisibility-inlines-hidden -std=c++11 -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wno-missing-field-initializers -pedantic -Wno-long-long -Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment -ffunction-sections -fdata-sections -Wall -std=c++11 -Wno-unused-parameter -Wno-unknown-warning-option -fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables -fno-stack-protector -fvisibility=hidden -fvisibility-inlines-hidden -fno-lto -O3 -g -Wno-variadic-macros -Wno-non-virtual-dtor -fPIE -fno-rtti -DGTEST_NO_LLVM_RAW_OSTREAM=1 -DGTEST_HAS_RTTI=0 -I/home/siadmin/jenkins/w/opensource/opensource_build/llvm/utils/unittest/googletest/include -I/home/siadmin/jenkins/w/opensource/opensource_build/llvm/utils/unittest/googletest -I/home/siadmin/jenkins/w/opensource/opensource_build/llvm/projects/compiler-rt/lib -I/home/siadmin/jenkins/w/opensource/opensource_build/llvm/projects/compiler-rt/lib/tsan/rtl -DGTEST_HAS_RTTI=0 -m64 -c -o tsan_sync_test.cc.x86_64.o /home/siadmin/jenkins/w/opensource/opensource_build/llvm/projects/compiler-rt/lib/tsan/tests/unit/tsan_sync_test.cc
>> clang-5.0: error: unable to execute command: Killed
>> clang-5.0: error: clang frontend command failed due to signal (use -v to see invocation)
>> clang version 5.0.0
>> Target: x86_64-unknown-linux-gnu
>> Thread model: posix
>> InstalledDir: /home/siadmin/jenkins/w/opensource/opensource_build/build/./bin
>> clang-5.0: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script.
>> clang-5.0: note: diagnostic msg:
>> ********************
>> 
>> PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
>> Preprocessed source(s) and associated run script(s) are located at:
>> clang-5.0: note: diagnostic msg: /tmp/tsan_sync_test-8d36d1.cpp
>> clang-5.0: note: diagnostic msg: /tmp/tsan_sync_test-8d36d1.sh
>> clang-5.0: note: diagnostic msg:
>> 
>> ********************
>> 
>> Sadly I don't have access to the failure preprocessed source or script that was generated, so I'm trying to reproduce it on my machine which might take longer since it is slower...
>> 
>> Douglas Yung
>> 
>>> -----Original Message-----
>>> From: llvm-commits [mailto:llvm-commits-bounces at lists.llvm.org] On Behalf Of
>>> Adrian Prantl via llvm-commits
>>> Sent: Thursday, March 16, 2017 13:16
>>> To: Evgenii Stepanov
>>> Cc: LLVM Commits
>>> Subject: Re: [llvm] r297971 - Salvage debug info from instructions about to be
>>> deleted
>>> 
>>> Is there a bot that catches this or otherwise any instructions to reproduce
>>> this?
>>> 
>>> thanks,
>>> adrian
>>> 
>>>> On Mar 16, 2017, at 1:13 PM, Evgenii Stepanov <eugeni.stepanov at gmail.com>
>>> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> ninja check-msan on linux/x86_64 has started using unlimited memory
>>>> and I suspect this change.
>>>> One common allocation is
>>>> 
>>>> #9 0x00007f40f6cfae0d operator new(unsigned long)
>>>> /build/gcc-4.8-mW1ufQ/gcc-4.8-4.8.4/build/x86_64-linux-gnu/libstdc++-v
>>>> 3/libsupc++/../../../../src/libstdc++-v3/libsupc++/new_op.cc:56:0
>>>> #10 0x00000000017e3a8d llvm::DIExpression::getImpl(llvm::LLVMContext&,
>>>> llvm::ArrayRef<unsigned long>, llvm::Metadata::StorageType, bool)
>>>> (/code/build-llvm/bin/clang-5.0+0x17e3a8d)
>>>> #11 0x0000000001dae195 prependDIExpr(llvm::DIBuilder&,
>>>> llvm::DIExpression*, bool, long)
>>>> (/code/build-llvm/bin/clang-5.0+0x1dae195)
>>>> #12 0x0000000001db539b std::_Function_handler<void
>>>> (llvm::DbgValueInst&),
>>>> llvm::salvageDebugInfo(llvm::Instruction&)::$_2>::_M_invoke(std::_Any_
>>>> data
>>>> const&, llvm::DbgValueInst&)
>>>> (/code/build-llvm/bin/clang-5.0+0x1db539b)
>>>> #13 0x0000000001dade35 llvm::findDbgValues(llvm::Value*,
>>>> std::function<void (llvm::DbgValueInst&)>)
>>>> (/code/build-llvm/bin/clang-5.0+0x1dade35)
>>>> #14 0x0000000001dae7f6 llvm::salvageDebugInfo(llvm::Instruction&)
>>>> (/code/build-llvm/bin/clang-5.0+0x1dae7f6)
>>>> #15 0x0000000001961964
>>>> llvm::InstCombiner::eraseInstFromFunction(llvm::Instruction&)
>>>> (/code/build-llvm/bin/clang-5.0+0x1961964)
>>>> #16 0x000000000196deb5 llvm::InstCombiner::run()
>>>> (/code/build-llvm/bin/clang-5.0+0x196deb5)
>>>> 
>>>> 
>>> 
>>> _______________________________________________
>>> llvm-commits mailing list
>>> llvm-commits at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
> <1.ii.gz>