LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 20893 - trunk 217475 and -g -O2 causing crash
Summary: trunk 217475 and -g -O2 causing crash
Status: RESOLVED FIXED
Alias: None
Product: new-bugs
Classification: Unclassified
Component: new bugs (show other bugs)
Version: trunk
Hardware: PC Linux
: P normal
Assignee: Adrian Prantl
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-09-10 04:05 PDT by David Binderman
Modified: 2014-11-11 20:03 PST (History)
7 users (show)

See Also:
Fixed By Commit(s):


Attachments
gzipped C++ source code (660.83 KB, application/x-gzip)
2014-09-10 04:05 PDT, David Binderman
Details
change DbgValMap to have set semantics (4.19 KB, patch)
2014-09-12 18:47 PDT, Adrian Prantl
Details
Bugpoint and delta-reduced testcase (91.68 KB, application/x-gzip)
2014-09-22 13:19 PDT, Adrian Prantl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description David Binderman 2014-09-10 04:05:30 PDT
Created attachment 13015 [details]
gzipped C++ source code

The attached preprocessed C++ source code, when compiled by today's trunk with
-g -O2, causes a crash.


clang: error: unable to execute command: Killed
clang: error: clang frontend command failed due to signal (use -v to see invocation)
clang version 3.6.0 (trunk 217475)
Target: x86_64-unknown-linux-gnu
Thread model: posix
Comment 1 David Binderman 2014-09-10 04:09:21 PDT
Stack backtrace

0  clang           0x00000000022f0005 llvm::sys::PrintStackTrace(_IO_FILE*) + 37
1  clang           0x00000000022f080b
2  libpthread.so.0 0x00000036b200f720
3  clang           0x0000000001c6dc62 llvm::SelectionDAG::TransferDbgValues(llvm::SDValue, llvm::SDValue) + 354
4  clang           0x0000000001bd56d8 llvm::SelectionDAG::Combine(llvm::CombineLevel, llvm::AliasAnalysis&, llvm::CodeGenOpt::Level) + 2072
5  clang           0x0000000001cafef9 llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 137
6  clang           0x0000000001cafd45 llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 2613
7  clang           0x0000000001caeb35 llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 933
8  clang           0x0000000001b15bf6
Comment 2 Eric Christopher 2014-09-10 13:24:00 PDT
Adrian? This looks like the stuff you've been touching.
Comment 3 Adrian Prantl 2014-09-10 18:39:55 PDT
Compiling this file uses over 24GiB of memory, all metadata. I'll have a look.
Comment 4 Eric Christopher 2014-09-10 18:41:44 PDT
Impressive. Most impressive.
Comment 5 Adrian Prantl 2014-09-12 18:46:30 PDT
What happens here is that SelectionDAG is combining two SDNodes and then merging their DbgValues via DAG.TransferDbgValues(), but SelectionDAG::AddDbgValue() doesn't check whether a DbgValue is already in that SDNode's list of DbgValues and happily adds all of them. The testcase with it's plethora of debug variables from layer over layers of inlined boost::* methods drives this into a pathologic situation where — when dagcombining a chain of instructions — our SDNode's DbgValMap is growing exponentially.

The attached patch changes the DbgValMap to have set semantics, which fixes the problem and reduced the memory usage to only ~500MB.

I'm still trying to come up with a usable testcase for this.
Comment 6 Adrian Prantl 2014-09-12 18:47:23 PDT
Created attachment 13034 [details]
change DbgValMap to have set semantics
Comment 7 Adrian Prantl 2014-09-22 13:19:12 PDT
Created attachment 13066 [details]
Bugpoint and delta-reduced testcase

Attached a bugpoint and delta-reduced testcase that has SelectionDAG insert two distinct but equivalent SDDebugValues to the same SDNode.
Unfortunately the testcase is still counting 2375 lines.
Comment 8 Frederic Riss 2014-11-11 20:03:55 PST
Fixed by r221709