[LLVMbugs] [Bug 4401] New: Assertion failure in ScheduleDAGRList: instruction released too many times
bugzilla-daemon at cs.uiuc.edu
bugzilla-daemon at cs.uiuc.edu
Tue Jun 16 10:40:53 PDT 2009
http://llvm.org/bugs/show_bug.cgi?id=4401
Summary: Assertion failure in ScheduleDAGRList: instruction
released too many times
Product: libraries
Version: trunk
Platform: PC
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Scalar Optimizations
AssignedTo: unassignedbugs at nondot.org
ReportedBy: reid.kleckner at gmail.com
CC: llvmbugs at cs.uiuc.edu
I'm working on unladen-swallow and I was running our regression suite with
python configured to always JIT compile everything, and I ran into this
assertion error:
*** Scheduling failed! ***
SU(1): 0x7f89479a2548: i64,ch = CopyFromReg 0x1238918, 0x7f8955387510
has been released too many times!
python: ScheduleDAGRRList.cpp:205:
void<unnamed>::ScheduleDAGRRList::ReleasePred(llvm::SUnit*, const llvm::SDep*):
Assertion `0' failed.
My platform triple is: x86_64-unknown-linux-gnu
The suite takes hours to run because it tests a lot of Python edge cases by
generating absurdly large fragments of code and having Python execute them and
LLVM doesn't like absurdly large code fragments, so I ran it under GDB in case
it crashed. I currently have it stopped at the assertion failure, and I'm
going to try to dig out the LLVM IR from the program so I can provide a stand
alone test case.
Here's the backtrace:
#0 0x00007f897a04f095 in raise () from /lib/libc.so.6
#1 0x00007f897a050af0 in abort () from /lib/libc.so.6
#2 0x00007f897a0482df in __assert_fail () from /lib/libc.so.6
#3 0x0000000000939418 in (anonymous namespace)::ScheduleDAGRRList::ReleasePred
()
#4 0x000000000093945a in (anonymous
namespace)::ScheduleDAGRRList::ReleasePredecessors ()
#5 0x000000000093a4bf in (anonymous
namespace)::ScheduleDAGRRList::ScheduleNodeBottomUp ()
#6 0x000000000093eb9c in (anonymous
namespace)::ScheduleDAGRRList::ListScheduleBottomUp ()
#7 0x000000000093fb60 in (anonymous namespace)::ScheduleDAGRRList::Schedule ()
#8 0x0000000000a1b241 in llvm::ScheduleDAG::Run ()
#9 0x00000000008c5fb4 in llvm::SelectionDAGISel::CodeGenAndEmitDAG ()
#10 0x00000000008c7339 in llvm::SelectionDAGISel::SelectBasicBlock ()
#11 0x00000000008c9615 in llvm::SelectionDAGISel::SelectAllBasicBlocks ()
#12 0x00000000008caa21 in llvm::SelectionDAGISel::runOnFunction ()
#13 0x0000000000ca4f55 in llvm::FPPassManager::runOnFunction ()
#14 0x0000000000ca538d in llvm::FunctionPassManagerImpl::run ()
#15 0x0000000000ca55b6 in llvm::FunctionPassManager::run ()
#16 0x00000000009a7ab9 in llvm::JIT::runJITOnFunctionUnlocked ()
#17 0x00000000009a82d1 in llvm::JIT::getPointerToFunction ()
#18 0x000000000057bcc1 in PyEval_EvalCodeEx (co=0x7f897b315160,
globals=0x7f88d965cda0, locals=0x7f88d965cda0, args=0x0, argcount=0,
kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0)
at Python/eval.cc:3763
#19 0x000000000057cca2 in PyEval_EvalCode (co=0xd22, globals=0xd22, locals=0x6)
at Python/eval.cc:541
#20 0x0000000000591bd0 in PyImport_ExecCodeModuleEx (
name=0x7fff83354c05 "longlist", co=0x7f897b315160,
pathname=0x7fff83353b40 "longlist.pyo") at Python/import.c:687
#21 0x0000000000592065 in load_compiled_module (
name=0x7fff83354c05 "longlist", cpathname=0x7fff83353b40 "longlist.pyo",
fp=<value optimized out>) at Python/import.c:815
#22 0x0000000000592c79 in import_submodule (mod=0x11cbc00,
subname=0x7fff83354c05 "longlist", fullname=0x7fff83354c05 "longlist")
at Python/import.c:2552
#23 0x00000000005931cd in load_next (mod=0x527e050, altmod=0x11cbc00,
p_name=<value optimized out>, buf=0x7fff83354c00 "test.longlist",
p_buflen=0x7fff83354bf0) at Python/import.c:2376
#24 0x0000000000593539 in PyImport_ImportModuleLevel (
name=<value optimized out>, globals=0x7f88da336d80,
locals=<value optimized out>, fromlist=0x11cbc00, level=-1)
at Python/import.c:2094
#25 0x0000000000573549 in builtin___import__ (self=<value optimized out>,
args=<value optimized out>, kwds=<value optimized out>)
at Python/bltinmodule.c:49
#26 0x00000000004fd81d in PyObject_Call (func=0x7f897b30a518,
arg=0x7f88d50e5f18, kw=0x0) at Objects/abstract.c:2487
#27 0x0000000000573d66 in PyEval_CallObjectWithKeywords (func=0x7f897b30a518,
arg=0x7f88d50e5f18, kw=0x0) at Python/eval.cc:42
#28 0x000000000056e980 in builtin_import_name (self=<value optimized out>,
args=<value optimized out>) at Python/bltinmodule.c:1170
#29 0x000000000057c8a2 in _PyEval_CallFunction (pp_stack=0x7fff83355de8,
oparg=<value optimized out>) at Python/eval.cc:3843
#30 0x00007f8908651cad in ?? ()
#31 0x00007f88da336d80 in ?? ()
#32 0x00007f8922969559 in ?? () from /usr/lib/libGL.so.1
#33 0x00007f897b32ca48 in ?? ()
#34 0x00007f891a72e3b0 in ?? ()
#35 0x0000000000000000 in ?? ()
As you can see it trails off into nonsense, because GDB can't make backtraces
for JITed code yet.
--
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
More information about the llvm-bugs
mailing list