Heaven sometimes crashes when loading with an error output : LLVM ERROR: Cannot select: target intrinsic %llvm.AMDIL.mad I can partially reproduce this bug. It happens from time to time on Heaven start. To reproduce it I use the Heaven launcher (using Archlinux AUR package), just untick fullscreen checkbox and choose 1024x768 and click run. If the crash is not triggered I close the unigine render window and just click once again "Run" and so on. It happens about once every 10 runs when I test. (I know it's not convenient at all to reproduce it but it is a very rare bug...) I also had it once with Heroes of Newerth. using R600_LLVM=0, radeon seems to be not hit by this problem. Using git head and r600g on BARTS HD6870. I might also add that I use these env vars (some are probably outdated...) R600_ENABLE_S3TC=1 R600_GLSL130=1 R600_STREAMOUT=1 Using Xorg 1.13 and linux 3.6.3
I was unclear about LLVM: I am using the llvm glsl backend when I trigger this error.
I saw this yesterday after rebuilding Mesa and running nexuiz. Running again worked without error. This is the second time I've seen it, the first was a couple of weeks ago, again after a rebuild of mesa this time with etqw. I couldn't reproduce, but did get more output - LLVM ERROR: Cannot select: target intrinsic %llvm.AMDIL.mad Stack dump: 0. Running pass 'Function Pass Manager' on module 'tgsi'. 1. Running pass 'AMDGPU DAG->DAG Pattern Instruction Selection' on function '@main' I am using llvm 3.1 on HD4890.
Does the environment variable DRAW_USE_LLVM=0 work around the problem as well? Can you get a backtrace for the crash?
I could reproduce the crash with DRAW_USE_LLVM=0. I did not manage to get a backtrace. I probably need to recompile LLVM with debug. I'll do it when I have time.
So I recompiled LLVM with debug symbols but I can't seem to get a backtrace... Looks like it's because the libGL is loaded via dlopen or something like that. Any hints on how to procedd with gdb ? I tried to use symbol-file and load libLLVM then setting a breakpoint where it prints the error but is didn't stop when it ran this code...
(In reply to comment #5) How are you specifying the breakpoint location? IME it's most reliable to specify the source code file and line, e.g. foobar.c:42
(In reply to comment #6) This is what I did and it never halted on the breakpoint. I'll try again when I have time.
(In reply to comment #7) > This is what I did and it never halted on the breakpoint. After the problem occurs, does 'info breakpoints' show that gdb was able to actually resolve the breakpoint location?
Created attachment 69326 [details] backtrace
Finally got it!
this was checked with llvm 3.1 and mesa b3921e1f53833420e0a0fd581f741744e7957a05
Created attachment 69334 [details] Possible fix This is a strange bug. There must be a race condition somewhere. Does this patch help? If it doesn't, can you reproduce this with an LLVM 3.2 tree: git fetch git://people.freedesktop.org/~tstellar/llvm master
(In reply to comment #12) > Created attachment 69334 [details] > Possible fix > > This is a strange bug. There must be a race condition somewhere. Does this > patch help? If it doesn't, can you reproduce this with an LLVM 3.2 tree: > > git fetch git://people.freedesktop.org/~tstellar/llvm master I should add you need to build the branch of LLVM with --enable-experimental-targets=AMDGPU
(In reply to comment #12) > Created attachment 69334 [details] > Possible fix > > This is a strange bug. There must be a race condition somewhere. Does this > patch help? If it doesn't, can you reproduce this with an LLVM 3.2 tree: > > git fetch git://people.freedesktop.org/~tstellar/llvm master With your patch applied I can't seem to reproduce the crash.
Not seen in a while with vanilla mesa, closing.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.