Bug 109048 - [amdgpu] [apitrace] Penumbra Overture crash in radeonsi_dri.so on RX580
Summary: [amdgpu] [apitrace] Penumbra Overture crash in radeonsi_dri.so on RX580
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: 18.3
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-12-13 08:51 UTC by Henri Valta
Modified: 2019-09-25 18:44 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
Coredump info (3.84 KB, text/plain)
2018-12-13 08:51 UTC, Henri Valta
Details
Full backtrace (10.68 KB, text/plain)
2018-12-13 08:51 UTC, Henri Valta
Details
apitrace (158.32 MB, application/x-xz)
2018-12-13 08:53 UTC, Henri Valta
Details
Savegame ready to explode (1.17 MB, text/plain)
2019-02-13 10:21 UTC, Henri Valta
Details

Description Henri Valta 2018-12-13 08:51:11 UTC
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
Comment 1 Henri Valta 2018-12-13 08:51:35 UTC
Created attachment 142800 [details]
Full backtrace
Comment 2 Henri Valta 2018-12-13 08:53:54 UTC
Created attachment 142801 [details]
apitrace
Comment 3 Timothy Arceri 2019-02-12 11:57:19 UTC
The trace seems to run without crashing for me with Mesa from git. Are you still having this issue?
Comment 4 Henri Valta 2019-02-12 19:26:24 UTC
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?
Comment 5 Timothy Arceri 2019-02-12 23:15:48 UTC
(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?
Comment 6 Henri Valta 2019-02-13 09:11:40 UTC
(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
Comment 7 Timothy Arceri 2019-02-13 09:55:41 UTC
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?
Comment 8 Henri Valta 2019-02-13 10:20:04 UTC
(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.
Comment 9 Henri Valta 2019-02-13 10:21:15 UTC
Created attachment 143371 [details]
Savegame ready to explode
Comment 10 Henri Valta 2019-02-13 19:05:32 UTC
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.
Comment 11 Henri Valta 2019-02-13 20:37:38 UTC
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?
Comment 12 Timothy Arceri 2019-02-17 23:10:07 UTC
(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.
Comment 13 Timothy Arceri 2019-02-17 23:11:41 UTC
What version of GCC are you using to build Mesa?
Comment 14 Henri Valta 2019-02-18 08:33:21 UTC
(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.
Comment 15 Henri Valta 2019-02-18 08:43:55 UTC
https://bugs.archlinux.org/task/61797
Comment 16 Timothy Arceri 2019-09-09 00:34:00 UTC
Is this still a problem for you? Or have updates to GCC fixed it?
Comment 17 GitLab Migration User 2019-09-25 18:44:13 UTC
-- 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.