| Bug ID | 96444 |
|---|---|
| Summary | GRID Autosport crash on loading race |
| Product | Mesa |
| Version | git |
| Hardware | Other |
| OS | All |
| Status | NEW |
| Severity | normal |
| Priority | medium |
| Component | Drivers/Gallium/radeonsi |
| Assignee | dri-devel@lists.freedesktop.org |
| Reporter | lorenz.bona@gmail.com |
| QA Contact | dri-devel@lists.freedesktop.org |
Created attachment 124407 [detai= ls] log file GRID Autosport crashes on start of race. It seems the same issue of this bug 93352, which is marked as FIXED= , but it isnt, I guess. I've run steam with this command: LIBGL_DEBUG=3Dverbose steam > log.txt until the game crashed. I've attached the log file. LLVM/mesa/xorg/drm are build from git, 08/06/2016. Let me know if I can provide more usefull log file.
| What | Removed | Added |
|---|---|---|
| Hardware | Other | x86-64 (AMD64) |
| OS | All | Linux (All) |
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 att= ach 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 u= se `bt full` to get a detailed backtrace.
Edit GridAutosport.sh in game directory.
#HAS_CATALYST=3D"$(grep fglrx /proc/modules)"
#if [ -n "${HAS_CATALYST}" ]; then
LD_PRELOAD=3D"../lib/x86_64/libtcmalloc_minimal.so:${LD_PRELOA=
D}"
export LD_PRELOAD
#fi
(In reply to Nicolai H=C3=A4hnle 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 t= o attach gdb > to the game. Once gdb has loaded, use `continue` to continue running t= he > 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.
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 comme= nt #5) > (In reply to Nicolai H=C3=A4hnle from comment #3) > > No, you just need to provide a backtrace. Since you're running th= e game via > > Steam, you could use `gdb -p <pid>` after the game has star= ted to attach gdb > > to the game. Once gdb has loaded, use `continue` to continue runn= ing the > > game. When it crashes, you should see a corresponding message in = gdb; then > > just use `bt full` to get a detailed backtrace. >=20 > Sorry for the delay. > I've tried to get a backtrace but I failed, don't know what I'm missin= g. > 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 ga= me 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/k= ai/.local/share/Steam/SteamApps/common/The Talos Principle/Bin/x64/Talos&qu= ot; > 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 4= 844, 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 i= ts 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 n= ote, that you might have to recreate the command line/environment the shell script is usu= ally setting in this case, so if you feel uncomfortable with reading a shell scr= ipt, 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
| What | Removed | Added |
|---|---|---|
| Attachment #124477 is obsolete | 1 |
Created attachment 124483 <=
a href=3D"attachment.cgi?id=3D124483&action=3Dedit" title=3D"gdb comple=
te log">[details]
gdb complete log
Okay, that's an error during shader compilation - I missed tha= t in the log you posted. Seems like a very large shader runs into problem with branch loweri= ng, probably something that's not properly implemented in LLVM yet. Can you run with the environment variable R600_DEBUG=3Dps,vs,gs,tcs,tes set= and post the log output? (This allows us to extract the problematic shader befo= re 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 combinat= ion like ps afx) to get a tree view of processes. Together with the CPU time sp= ent in each process, it's a good help in figuring out which is the correct proc= ess to attach to.
Here you are, I've run this command: R600_DEBUG=3Dps,vs,gs,tcs,tes steam > debug.log and I've tried to start a career on GRID. Ty
Created attachment 1244=
94 [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 l=
east 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 L=
LVM
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 o=
ne
confirm what LLVM files Radeonsi has linked to? I know 3.9 is mentioned abo=
ve
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 t=
hat
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 work=
ing
with Grid (via the Padoka PPA) was around the end of April. I don't know wh=
at
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 v= ersion from the padoka PPA (package version 1:3.9~svn274905-0~x~padoka0) and Grid Autosport= is once again working with my R9 270X.
| What | Removed | Added |
|---|---|---|
| Status | NEW | RESOLVED |
| Resolution | --- | FIXED |
(In reply to Adam Lyall from comment #17) > It seems this issue may have been resolved. I go= t 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= .