[0.17.69][0.17.73] Linux game crashes on startup with mesa 19.3.0-devel

[movax20h]

So,

I don't know if this is a bug in Mesa or Factorio, but I don't have any issues with Mesa in other titles, so reporting here. I might try to bisect the issue further, but this is what I got.

I am experiencing reliable startup crashes with few versions of Factorio, including 0.17.69 and 0.17.73 when using Mesa 19.3.0-devel (Versions: git-cdff9b00e1 ; git-5658b13fb6 ) from git. The issues doesn't occur when using Mesa 19.2.1.

The crash looks to be in the Factorio code itself, and always with the same stack trace, not when calling any OpenGL functions or in dri drivers, so maybe it is Factorio doing something wrong instead. However the stack trace is really weird, as it shows some elements of the stack and std c++ library calling back to factorio, when they clearly can't (like string class), so maybe there is some extra stack corruption issue garbling the stack.

I am using AMD Radeon Fury X, 4GB VRAM.

I checked manually glxinfo with older Mesa 19.2.1 and my 19.3.0-devel (git-cdff9b00e1), and new Mesa has few extra extensions that maybe affects Factorio initialization? New ones: GL_MESA_framebuffer_flip_y, GL_EXT_EGL_sync, GL_EXT_shader_image_load_store.

The game also crashes with --gfx-safe-mode , but with slightly different stack trace (second attachment).

[posila]

Hello, please don't report crashes to us when using developer build of graphics drivers (well, unless you are driver developer and can pinpoint how we use OpenGL wrong; or Direct3D for that matter).

The last line that makes sense in the stacktrace is

Code: Select all

#30 (nil) in LinkedProgram::LinkedProgram(ShaderOpenGL const*, ShaderOpenGL const*, bool) at /tmp/factorio-build-w0Ndli/src/Graphics/OpenGL/PipelineStateObjectOpenGL.cpp:90

everything above that is nonsense (except for the CrashHandler stuff at the top)

Line 90 is: glDetachShader(this->id, vertShader->id);
But the line number can be +-1 wrong and it could have been actually the line above it: glLinkProgram(this->id);

It's also noteworthy at the time of crash it already successfully linked several other shader programs, so it is specific to particular shader (fullscreen-quad.vert and one of compress-ycocg-dxt.frag, compress-rygDXT.frag or compress-bc4.frag)

[movax20h]

Yes, I do a bit of driver development.

I just didn't notice there is a call to glLinkProgram hidden there. That makes much more sense, and I is very likely a bug in shader compiler in my drivers. I will investigate it on Mesa side, do apitrace and bisect code in Mesa git.

Thanks for your help.

[posila]

If you manage to diagnose the issue and fix it or report it up the chain, then I thank you!

[movax20h]

Just a quick question.

What would you recommend to run Factorio under gdb or valgrind? Right now if I try to do that, it starts steam, asks for confirmation, and also does trap SIGSEGV, so the crash can't be captured in the gdb anyway.

Should I maybe download factorio build from factorio.com (I do have an account and access to the binaries there), or is there some flag to do it?

Thanks in advance.

[posila]

You can get non-Steam binnaries if you register on factorio.com and link your account with your Steam account; but I think demo will crash also https://factorio.com/download-demo/experimental

For 0.17.74 (today) I'll add --no-crash-handler CIL parameter

[movax20h]

Indeed, I was able to reproduce same issue with demo. Makes bisecting way quicker than a steam version. Thank for the hint.

Awesome about the new flag!

I reported an issue upstream https://gitlab.freedesktop.org/mesa/mesa/issues/1999 , it is a tricky bug , that only shows up with very specific compiler flags.

Definitively not a Factorio bug.

Thanks again.

[movax20h]

Just tested --no-crash-handler with 0.17.74 binaries. It does work perfectly, and I was able to grab correct stack traces including line number information and inspect state of Mesa driver variables for some extra debugging using gdb.

[posila]

Nice. Thank you for reporting it upstream, I can see it was fixed promptly.

[movax20h]

It got fixed quickly upstream indeed. For reference:

https://gitlab.freedesktop.org/mesa/mes ... 57d242473a
https://gitlab.freedesktop.org/mesa/mes ... uests/2473

Cheers,
end of topic.

[Rseding91]

It got fixed quickly upstream indeed. For reference:

https://gitlab.freedesktop.org/mesa/mes ... 57d242473a
https://gitlab.freedesktop.org/mesa/mes ... uests/2473

Cheers,
end of topic.

On the original report you mentioned leaks in the game and that you had uploaded a log file with them yet I don't see any log file on the report. We also run valgrind with leak detection so I'm surprised that it would show anything.

Can you give me the full log file that you're saying is showing leaks?

[movax20h]

On the original report you mentioned leaks in the game and that you had uploaded a log file with them yet I don't see any log file on the report. We also run valgrind with leak detection so I'm surprised that it would show anything.

Can you give me the full log file that you're saying is showing leaks?

It was here: https://gitlab.freedesktop.org/mesa/mes ... -trace.txt referenced here https://gitlab.freedesktop.org/mesa/mesa/issues/1999 (there is link there in the bug report to it).

You can safely ignore the valgrind errors about memory leaks from my original Mesa bug report. The binary crashed before normal termination, so obviously it will have "memory leaks".

I did a quick test with valgrind, and there are some minor issues, but nothing serious so far, but looks to be real issue. The game is so slow that is really hard to test much. I can open separate issue for this.

[movax20h]

Valgrind stuff reported separately: viewtopic.php?f=7&t=77344