|Summary:||radeonsi/llvm SIGABRT in Antichamber (UDK)|
|Product:||Mesa||Reporter:||Christoph Haag <haagch>|
|Component:||Drivers/Gallium/radeonsi||Assignee:||Default DRI bug account <dri-devel>|
|Status:||RESOLVED DUPLICATE||QA Contact:|
|i915 platform:||i915 features:|
|Bug Depends on:||75276|
backtrace without debug symbols
first short backtrace, then full backtrace with debug symbols
last few lines before crash with MESA_GLSL=dump
dmesg with GPU lockup
Description Christoph Haag 2014-02-19 15:08:28 UTC
Created attachment 94363 [details] backtrace without debug symbols HD 7970M, mesa recent git, llvm 3.5 recent svn. Antichamber based on Unreal Engine is available in the latest Humble Bundle. The crash doesn't seem to happen deterministically, I produced such a crash two times now by playing the game for a few minutes and then it randomly crashed. UDKGame-Linux: /build/lib32-llvm-svn/src/llvm/include/llvm/CodeGen/SlotIndexes.h:417: llvm::SlotIndex llvm::SlotIndexes::getInstructionIndex(const llvm::MachineInstr*) const: Assertion `itr != mi2iMap.end() && "Instruction not found in maps."' failed. Program received signal SIGABRT, Aborted. 0xf7fdb430 in __kernel_vsyscall () The backtrace I attached is without debug symbols so maybe isn't too informative. Later I will compile with debug symbols and provide a better one if needed.
Comment 1 Christoph Haag 2014-02-19 19:11:30 UTC
Created attachment 94379 [details] first short backtrace, then full backtrace with debug symbols Okay, so here is a full backtrace with debugging information.
Comment 2 Christoph Haag 2014-02-19 19:35:52 UTC
Created attachment 94380 [details] last few lines before crash with MESA_GLSL=dump So because it looks like it happens when compiling shaders I ran it with MESA_GLSL=dump. It loads and compiles most shaders at the beginning, that worked fine so I cut it off. It occassionally seems to load new shaders, so after a while of gameplay with no output the attached stuff was printed and then immediately after that the game crashed.
Comment 3 Michel Dänzer 2014-02-20 04:01:18 UTC
(In reply to comment #2) > So because it looks like it happens when compiling shaders I ran it with > MESA_GLSL=dump. Please use R600_DEBUG=ps,vs instead of MESA_GLSL=dump.
Comment 4 Christoph Haag 2014-02-20 10:02:17 UTC
Created attachment 94423 [details] with R600_DEBUG=ps,vs Wow, took me an hour of gameplay this time and quite a lot of loaded shaders in that time before it happened. It looks relatively random, i.e. doesn't crash at the same points in the game.
Comment 5 Tom Stellard 2014-02-24 17:48:24 UTC
Can you try this patch: https://bugs.freedesktop.org/attachment.cgi?id=94675
Comment 6 Tom Stellard 2014-03-03 19:54:59 UTC
Can you try this branch: http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes
Comment 7 VOT Productions 2014-04-12 11:55:03 UTC
HD 7750, Mesa-git, LLVM 3.5-svn. Sanctum 2 crashes with a similar error when loading. 417: llvm::SlotIndex llvm::SlotIndexes::getInstructionIndex(const llvm::MachineInstr*) const: Assertion `itr != mi2iMap.end() && "Instruction not found in maps."' failed. Always crashes in the same place, and the same time.
Comment 8 Tom Stellard 2014-04-28 20:52:34 UTC
Can you test this branch: http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes-v2
Comment 9 Tom Stellard 2014-04-29 21:38:03 UTC
Updated v3 branch here: http://cgit.freedesktop.org/~tstellar/llvm/log/?h=si-spill-fixes-v3
Comment 10 Christoph Haag 2014-04-29 22:53:51 UTC
Sorry for first only answering for Sanctum2, in Antichamber it often takes a long time to reach the point where it happens. Sanctum2 starts and runs okay now I guess. But there are pretty big problems with it and I have no idea whether they are caused by this here or not: As soon as the fullscreen window with Sanctum2 isn't displayed anymore (e.g. minimizing or switching workspaces), the whole X display is getting scrambled, but restores immediately when displaying the game window again. (Could of course be just the PRIME setup). I started setting the graphics options higher and higher and at some point, got a GPU lockup. No gpu faults like in upvoid, just a lock up I think (blocked and resetted and stuff). I got a complete machine lockup moments later and didn't get more information. Again, no idea if it's related. But the register spilling implementation at least works and seems to not cause any direct problems.
Comment 11 Christoph Haag 2014-04-29 23:13:42 UTC
Created attachment 98201 [details] dmesg with GPU lockup Yea, this is maybe going off topic, but I'm a bit tired, so here's the dmesg with gpu lockup. It always happens when going to Sanctum2's advanced graphics setting, right when enabling "Lichstrahlen" or light rays or whatever it's called in english. The rest of the game seems to be fine as far as I have seen walking around for a pretty short time.
Comment 12 Tom Stellard 2014-05-16 19:29:40 UTC
Can you try this LLVM patch: https://bugs.freedesktop.org/attachment.cgi?id=99169
Comment 13 Christoph Haag 2014-05-16 21:39:20 UTC
(In reply to comment #12) > Can you try this LLVM patch: > > https://bugs.freedesktop.org/attachment.cgi?id=99169 Sorry, but on top of what revision? Latest upstream trunk (209031) says: SIInstrInfo.cpp:197:41: Fehler: falsche Benutzung des unvollständigen Typs »const class llvm::Function« LLVMContext &Ctx = MF->getFunction()->getContext(); ("wrong usage of partial type" or something)
Comment 14 Tom Stellard 2014-05-16 22:20:43 UTC
(In reply to comment #13) > (In reply to comment #12) > > Can you try this LLVM patch: > > > > https://bugs.freedesktop.org/attachment.cgi?id=99169 > > Sorry, but on top of what revision? > > Latest upstream trunk (209031) says: > > SIInstrInfo.cpp:197:41: Fehler: falsche Benutzung des unvollständigen Typs > »const class llvm::Function« > LLVMContext &Ctx = MF->getFunction()->getContext(); > > ("wrong usage of partial type" or something) I will post a new patch when I get a chance. You should be able to fix this by adding #include "llvm/IR/Function.h" to the includes in SIInstrInfo.cpp