Created attachment 142799 [details] Coredump info Penumbra Overture game from Steam crashes reliably when trying to detonate the TNT barrel. The crash seems to happen in radeonsi_dri.so Stack trace of thread 16178: #0 0x00000000f44d5dc1 amdgpu_bo_map (radeonsi_dri.so) #1 0x00000000f448a874 si_texture_transfer_map (radeonsi_dri.so) #2 0x00000000f4ae24b1 tc_transfer_map (radeonsi_dri.so) #3 0x00000000f46ee64b pipe_transfer_map_3d (radeonsi_dri.so) #4 0x00000000f46dfb48 st_MapTextureImage (radeonsi_dri.so) #5 0x00000000f46b3c85 store_texsubimage (radeonsi_dri.so) #6 0x00000000f46e2aca st_TexSubImage (radeonsi_dri.so) #7 0x00000000f46e4650 st_TexImage (radeonsi_dri.so) #8 0x00000000f46a7085 teximage (radeonsi_dri.so) #9 0x00000000f46a8a78 _mesa_TexImage1D (radeonsi_dri.so) #10 0x00000000f7d44236 glTexImage1D (glxtrace.so) System specification: AMD Ryzen 7 2700X MSI X470 Gaming Pro/latest bios MSI RX580 Armor 8G (1d:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Ellesmere [Radeon RX 470/480/57$ Arch linux 64 bit, but the game is 32 bit Kernel 4.19.8-arch1-1-ARCH Mesa 18.3.1-1
Created attachment 142800 [details] Full backtrace
Created attachment 142801 [details] apitrace
The trace seems to run without crashing for me with Mesa from git. Are you still having this issue?
Yes, currently with mesa 18.3.3 it is still crashing as before. Do you think trying git version would be helpful in solving this?
(In reply to Henri Valta from comment #4) > Yes, currently with mesa 18.3.3 it is still crashing as before. > Do you think trying git version would be helpful in solving this? I just tried a build of 18.3.3 and it didn't crash for me either. Just to be clear, does the trace actually crash for you? Or does it only happen when your running the game?
(In reply to Timothy Arceri from comment #5) > I just tried a build of 18.3.3 and it didn't crash for me either. Just to be > clear, does the trace actually crash for you? Or does it only happen when > your running the game? I thought the trace also crashed, but now checking more closely I see the crash I saw in coredumpctl list was from the recording run, not the replay run. Is there any way to maybe make the trace more useful? I see the last line with verbose replay says "49801900 @0 glTexImage1D(target = GL_TEXTURE_1D, level = 0, internalformat = 3, width = 256, border = 0, format = GL_RGB, type = GL_UNSIGNED_BYTE, pixels = blob(768)) // incomplete" so does this mean the trace for the glTexImage1D is not executed with the trace as it's incomplete? I believe this is the command where the crash happens, according to the backtrace
Maybe you could try attaching a save game near a tnt barrel instead as I have the game and could try reproduce that way. Or you could try bisecting mesa if you know how to do that?
(In reply to Timothy Arceri from comment #7) > Maybe you could try attaching a save game near a tnt barrel instead as I > have the game and could try reproduce that way. > > Or you could try bisecting mesa if you know how to do that? I'll try to find a working mesa version to start the bisection, but as this is a new computer build, I have never actually had a working version with it. Might be a couple of days before I have the time. I have also attached a savegame. Now with quicksave feature enabled, it's right at the explosion stage. Just light the fuse with lighter from inventory.
Created attachment 143371 [details] Savegame ready to explode
Looking to start the bisect run now. It took a bit of time to reproduce the crash with plain git build. It seems that the crash only happens when mesa is built with CFLAGS="-O2" If I omit the O2, then the game works fine.
The bisection did not help much. The earliest commits I could test were somewhere between 18.1.9 and 18.2.0-rc1 and they also had the same issue. Earlier commits had problems with LLVM compiling shaders and game only gave black screen and errors like this: LLVM failed to compile shader LLVM triggered Diagnostic Handler: <unknown>:0:0: in function main <{ i32, i32, i32, i32, i32, float, float, float, float, float, float, float, float, float, float, float, float, float, float, float }> ([0 x <4 x i32>] addrspace(6)*, [0 x <8 x i32>] addrspace(6)*, [0 x <4 x i32>] addrspace(6)*, [0 x <8 x i32>] addrspace(6)*, float, i32, <2 x i32>, <2 x i32>, <2 x i32>, <3 x i32>, <2 x i32>, <2 x i32>, <2 x i32>, float, float, float, float, float, i32, i32, float, i32, float, float, float, float): unsupported call from graphics shader of function llvm.amdgcn.image.sample.v4f32.v2f32.v8i32 Would there be any benefit to try continue bisecting earlier? If so, any idea how to fix the LLVM issue?
(In reply to Henri Valta from comment #10) > Looking to start the bisect run now. > > It took a bit of time to reproduce the crash with plain git build. It seems > that the crash only happens when mesa is built with CFLAGS="-O2" > > If I omit the O2, then the game works fine. Thanks for the save game, however it seems to run without crashing on my machine. I wonder if this is actually a compiler bug rather than a Mesa bug given your find above.
What version of GCC are you using to build Mesa?
(In reply to Timothy Arceri from comment #13) > What version of GCC are you using to build Mesa? It's from arch linux package 8.2.1+20181127-1 >I wonder if this is actually a compiler bug rather than a Mesa bug given your find above. I'll open a bug for the arch mesa package and link it to this, so the people there who know what's going on with the gcc version might be able to help.
https://bugs.archlinux.org/task/61797
Is this still a problem for you? Or have updates to GCC fixed it?
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1349.
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.