Bug 96444

Hi Lorenzo, thanks for your report.

Can you build Mesa with debug symbols (configure with --enable-debug -- or install debug symbols in case you're using pre-built packages) and provide a backtrace of the crash?

Hi Nicolai,
mesa is already built with --enable-debug flag.

I'm missing something?

No, you just need to provide a backtrace. Since you're running the game via Steam, you could use `gdb -p <pid>` after the game has started to attach gdb to the game. Once gdb has loaded, use `continue` to continue running the game. When it crashes, you should see a corresponding message in gdb; then just use `bt full` to get a detailed backtrace.

Edit GridAutosport.sh in game directory.

#HAS_CATALYST="$(grep fglrx /proc/modules)"
#if [ -n "${HAS_CATALYST}" ]; then
	LD_PRELOAD="../lib/x86_64/libtcmalloc_minimal.so:${LD_PRELOAD}"
	export LD_PRELOAD
#fi

(In reply to Nicolai Hähnle from comment #3)
> No, you just need to provide a backtrace. Since you're running the game via
> Steam, you could use `gdb -p <pid>` after the game has started to attach gdb
> to the game. Once gdb has loaded, use `continue` to continue running the
> game. When it crashes, you should see a corresponding message in gdb; then
> just use `bt full` to get a detailed backtrace.

Sorry for the delay.
I've tried to get a backtrace but I failed, don't know what I'm missing.
I've attached gdb log file.

@Vladimir I've tried your trick but it doesn't work, I think this is a different issue. Ty btw.

Created attachment 124477 [details]
gdb log

Hey Lorenzo,
I can't weigh in on GRID, but I can give you some pointers with your GDB troubles.

(In reply to Lorenzo Bona from comment #5)
> (In reply to Nicolai Hähnle from comment #3)
> > No, you just need to provide a backtrace. Since you're running the game via
> > Steam, you could use `gdb -p <pid>` after the game has started to attach gdb
> > to the game. Once gdb has loaded, use `continue` to continue running the
> > game. When it crashes, you should see a corresponding message in gdb; then
> > just use `bt full` to get a detailed backtrace.
> 
> Sorry for the delay.
> I've tried to get a backtrace but I failed, don't know what I'm missing.
> I've attached gdb log file.

Your log in attachment 124477 [details] looks suspiciously like you attached GDB to the shell script launching the actual binary of the game. You need to attach to the game itself.

grep the output of ps once you've launched the game for that name of the game to find the right process to attach to. Since the shell is launched right before the actual game, you'll often find the next PID after the shell to be the game.

For The Talos Principle it just looked like this:
$ ps a | grep -i talos
> 4843 pts/13   S+   0:00 /bin/sh -c "/home/kai/.local/share/Steam/SteamApps/common/The Talos Principle/Bin/x64/Talos"
> 4844 pts/13   Rl+  0:19 /home/kai/.local/share/Steam/SteamApps/common/The Talos Principle/Bin/x64/Talos

As you can see, there are two processes and I would need to attach GDP to 4844, the first is the shell launching the game (in this case directly, but again, there are some games which have their own launcher script/launcher that launches the actual game, if you're unsure what the actual binary is, check the game folder in $HOME/.local/share/Steam/SteamApps/common).

Depending on the game you could also try to launch the game directly from its folder with GDB. For this to work you need to add a steam_appid.txt to the top level of the game folder with the App ID as its content for most games. (The easiest way to find the ID is to check the store URL for your game. Then numeric value after "/app/" is what you're looking for). Please note, that you might have to recreate the command line/environment the shell script is usually setting in this case, so if you feel uncomfortable with reading a shell script, don't do this.

Finally, I managed to get the full backtrace. :)
Ty Kay for your usefull explanation.

I used HTOP to control processes and wit GRID you have to use: not the 1st, not the 2nd but the 3rd PID!!! :D

Created attachment 124483 [details]
gdb complete log

Okay, that's an error during shader compilation - I missed that in the log you posted. Seems like a very large shader runs into problem with branch lowering, probably something that's not properly implemented in LLVM yet.

Can you run with the environment variable R600_DEBUG=ps,vs,gs,tcs,tes set and post the log output? (This allows us to extract the problematic shader before it is passed to LLVM - the output will be rather large.)

P.S.: For future reference, it's helpful to use `ps f` (maybe in a combination like ps afx) to get a tree view of processes. Together with the CPU time spent in each process, it's a good help in figuring out which is the correct process to attach to.

Here you are, I've run this command:

R600_DEBUG=ps,vs,gs,tcs,tes steam > debug.log
and I've tried to start a career on GRID.

Ty

Created attachment 124491 [details]
debug log

Created attachment 124494 [details]
crashing shader .ll file

Thanks, Lorenzo. I've extracted the last shader, but unfortunately I cannot reproduce the crash with standalone llc on the latest LLVM. What GPU do you have / what does glxinfo say?

Hi,
my GPU is a R7-265.
I haven't built LLVM since 08/06, so it's 5 day old.

I can try to rebuild LLVM today.

Just confirming I've had the same issue on my R9 270x for at least the last 3 weeks using Padoka PPA. I checked out older commits but none worked so when I saw this report and the mention about LLVM I've built the latest Mesa and LLVM but Grid Autosport still crashes just as a race is about to load.

Some bits of glxinfo:
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: X.Org (0x1002)
    Device: AMD PITCAIRN (DRM 2.43.0 / 4.6.0-040600rc6-generic, LLVM 3.9.0) (0x6810)
    Version: 12.1.0
    Accelerated: yes
    Video memory: 2048MB
    Unified memory: no
    Preferred profile: core (0x1)
    Max core profile version: 4.2
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.0
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD PITCAIRN (DRM 2.43.0 / 4.6.0-040600rc6-generic, LLVM 3.9.0)
OpenGL core profile version string: 4.2 (Core Profile) Mesa 12.1.0-devel (git-9ee3f09)
OpenGL core profile shading language version string: 4.20
---
OpenGL version string: 3.0 Mesa 12.1.0-devel (git-9ee3f09)
OpenGL shading language version string: 1.30

This is my first time building LLVM so hopefully I got it right? How does one confirm what LLVM files Radeonsi has linked to? I know 3.9 is mentioned above but I'm not sure if that is the version from the package repository.

Next I built against LLVM 3.8 and it worked! The race loaded and played just fine. It did crash at the end of the race (after the driver listings) but that could just be a bug in Grid itself (it is quite buggy on both Windows and Linux).

I was away from this machine for a month and the last time I recall it working with Grid (via the Padoka PPA) was around the end of April. I don't know what version of LLVM 3.9svn was in use at that time.

I can confirm what Adam said.

I've builded mesa against LLVM 3.8 (debian sid) and GRID is working as expected, no crashes or hangs.

It seems this issue may have been resolved. I got a new llvm version from the padoka PPA (package version 1:3.9~svn274905-0~x~padoka0) and Grid Autosport is once again working with my R9 270X.

(In reply to Adam Lyall from comment #17)
> It seems this issue may have been resolved. I got a new llvm version from
> the padoka PPA (package version 1:3.9~svn274905-0~x~padoka0) and Grid
> Autosport is once again working with my R9 270X.

OK. Closing then. Feel free to reopen if you encounter the same crash again.