Bug 109048

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.