[0.17.79] Demo crashes immediately (Ubuntu 20.04, Mesa driver 20.0.4, Intel Iris)

[majortal]

See attached logs.

[majortal]

Hello?
Isn't this a showstopper bug? Nothing works?
How can I help?

[valneq]

Have you tried the 0.18 demo? Does that crash, too?
You can find it here:
https://www.factorio.com/download-demo/experimental

[Rseding91]

Thanks for the report however:

* When I test the demo it works perfectly
* You seem to be the only person reporting having an issue
* The stack trace failed to symbolize (typical on Linux machines)
* The stack trace is 2 entries long (that typically means it crashed before it even gets to executing a line of code the game knows anything about)

All of the above in combination with the fact you're running Linux make me say the issue is something related to your systems configuration and not anything we control in code we've written.

Virtually every 'mysterious issue' crash report we've had where the player was running Linux has ended up being some configuration/driver/software issue on the players side.

However, if you're able to find a way that I can reproduce the issue on my machine (or if you can reproduce it with a correctly symbolized stack trace) I'll be happy to try to look into it more.

[majortal]

Have you tried the 0.18 demo? Does that crash, too?
You can find it here:
https://www.factorio.com/download-demo/experimental

Yes, the 0.18.31 version crashes the same way.

[majortal]

Thanks for the report however:

* When I test the demo it works perfectly
* You seem to be the only person reporting having an issue
* The stack trace failed to symbolize (typical on Linux machines)
* The stack trace is 2 entries long (that typically means it crashed before it even gets to executing a line of code the game knows anything about)

All of the above in combination with the fact you're running Linux make me say the issue is something related to your systems configuration and not anything we control in code we've written.

Virtually every 'mysterious issue' crash report we've had where the player was running Linux has ended up being some configuration/driver/software issue on the players side.

However, if you're able to find a way that I can reproduce the issue on my machine (or if you can reproduce it with a correctly symbolized stack trace) I'll be happy to try to look into it more.

Thanks for the feedback.
What's the next step? Are there any flags I can tweak? I can do some basic debugging but I need a pointer to the right direction.
Are there any environmental concerns I should look at? Graphics driver?
Missing libraries from my install? I have a vanilla Ubuntu 20.04 install.

[Rseding91]

Thanks for the feedback.
What's the next step? Are there any flags I can tweak? I can do some basic debugging but I need a pointer to the right direction.
Are there any environmental concerns I should look at? Graphics driver?
Missing libraries from my install? I have a vanilla Ubuntu 20.04 install.

I have no next steps, sorry. Maybe one of the linux guys could point you somewhere. But neither of them have any issues running the game. My recommendation has always been: install Windows.

[movax20h]

Thanks for the report however:

* When I test the demo it works perfectly
* You seem to be the only person reporting having an issue
* The stack trace failed to symbolize (typical on Linux machines)
* The stack trace is 2 entries long (that typically means it crashed before it even gets to executing a line of code the game knows anything about)

All of the above in combination with the fact you're running Linux make me say the issue is something related to your systems configuration and not anything we control in code we've written.

Virtually every 'mysterious issue' crash report we've had where the player was running Linux has ended up being some configuration/driver/software issue on the players side.

However, if you're able to find a way that I can reproduce the issue on my machine (or if you can reproduce it with a correctly symbolized stack trace) I'll be happy to try to look into it more.

Thanks for the feedback.
What's the next step? Are there any flags I can tweak? I can do some basic debugging but I need a pointer to the right direction.
Are there any environmental concerns I should look at? Graphics driver?
Missing libraries from my install? I have a vanilla Ubuntu 20.04 install.

Hi majortal. The crash is rather strange. It could be a hardware issue, but lets try this.

But it is very likely an issue with Mesa 20.0.4 and possibly GCC compiler.

First make sure you have gdb and debug symbols installed to ease troubleshooting:

Code: Select all

sudo apt install ubuntu-dbgsym-keyring
echo -e "deb http://ddebs.ubuntu.com focal main restricted universe multiverse\ndeb http://ddebs.ubuntu.com focal-updates main restricted universe multiverse\ndeb http://ddebs.ubuntu.com focal-proposed main restricted universe multiverse" | sudo tee -a /etc/apt/sources.list.d/ddebs.list
sudo apt update
sudo apt install -y gdb valgrind debian-goodies binutils strace libbsd0-dbgsym libx11-6-dbgsym libxcb1-dbgsym libxdmcp6-dbg  libx11-6-dbgsym libglx-mesa0-dbgsym libglx0-dbgsym libc6-dbg libdrm2-dbgsym libdrm-intel1-dbgsym libgl1-mesa-dri-dbgsym libvorbis0a-dbgsym libvorbisenc2-dbgsym libogg-dbg libdbus-1-3-dbgsym libz3-4-dbgsym zlib1g-dbgsym libzstd1-dbgsym liblz4-1-dbgsym liblzma5-dbgsym libsystemd0-dbgsym libtinfo5-dbgsym libtinfo6-dbgsym libstdc++6-10-dbg libuuid1-dbgsym libxrender1-dbgsym libxshmfence1-dbgsym libxext6-dbg libxcursor1-dbgsym libxss1-dbgsym libxfixes3-dbgsym libxrandr2-dbgsym libxau6-dbg libwrap0-dbgsym libexpat1-dbgsym  libelf1-dbgsym libsndfile1-dbgsym libffi7-dbgsym libpulse0-dbgsym  libxcb-dri2-0-dbgsym libxcb-dri3-0-dbgsym libxcb-glx0-dbgsym  libxcb-present0-dbgsym libxcb1-dbgsym libgcc-s1-dbgsym libllvm9-dbgsym

Once this is installed, continue below.

In terminal from a normal user do this:

Code: Select all

$ gdb --args ./bin/x64/factorio --no-crash-handler

Once in gdb, give it a command "r" (for run). The game should start. When it crashes, do "bt full" (for backtrace full), and report back what it is saying.

If this doesn't help try running using valgrind (this is going to be very very slow, it can take 10 minutes before the start of the game):

Code: Select all

$ valgrind ./bin/x64/factorio --no-crash-handler

And report back what it is saying.

[majortal]

Oh hey - thanks!!
I ran it in the debugger and got this traceback:
Thread 1 "factorio" received signal SIGSEGV, Segmentation fault.
0x00007ffff3192838 in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
(gdb) bt full
#0 0x00007ffff3192838 in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
No symbol table info available.
#1 0x00007ffff319393b in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
No symbol table info available.
#2 0x00007ffff3357de4 in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
No symbol table info available.
#3 0x00007ffff316ee5d in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
No symbol table info available.
#4 0x00007ffff316fa95 in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
No symbol table info available.
#5 0x00007ffff27ae774 in ?? () from /usr/lib/x86_64-linux-gnu/dri/iris_dri.so
No symbol table info available.
#6 0x0000000000c6e189 in GraphicsInterfaceOpenGL::swapBuffers () at /tmp/factorio-build-qf6LF5/src/Graphics/OpenGL/GraphicsInterfaceOpenGL.cpp:260
No locals.
#7 0x00000000005f4f2e in SDLWindow::swap () at /tmp/factorio-build-qf6LF5/src/Graphics/SDLWindow.cpp:355
No locals.
#8 0x000000000065493f in GlobalContext::swapRenderBuffers () at /tmp/factorio-build-qf6LF5/src/GlobalContext.cpp:1427
No locals.
#9 0x0000000000ec37ce in GlobalContext::swapRenderBuffers () at /tmp/factorio-build-qf6LF5/src/GlobalContext.cpp:1389
No locals.
#10 LoadingSplashScreen::render () at /tmp/factorio-build-qf6LF5/src/Graphics/LoadingSplashScreen.cpp:110
No locals.
#11 0x0000000000fcdaa1 in LoadingSplashScreen::LoadingSplashScreen () at /tmp/factorio-build-qf6LF5/src/Graphics/LoadingSplashScreen.cpp:41
No locals.
#12 0x00000000011e82c2 in GlobalContext::init () at /tmp/factorio-build-qf6LF5/src/GlobalContext.cpp:466
No locals.
#13 0x00000000011f219b in MainLoop::run(Filesystem::Path const&, Filesystem::Path const&, bool, bool, std::function<void ()>, Filesystem::Path const&, MainLoop::HeavyMode) ()
at /tmp/factorio-build-qf6LF5/src/MainLoop.cpp:269
No locals.
#14 0x00000000005aec2d in main () at /tmp/factorio-build-qf6LF5/src/Main.cpp:1087
No locals.
(gdb) ,


Which lead me to this bug:
https://bugs.launchpad.net/ubuntu/+sour ... ug/1877879

and the workaround to:
export MESA_LOADER_DRIVER_OVERRIDE=i965

...and now the game loads.

Thanks!

[movax20h]

Hi majortal.

Yes, as suspected this is a compiler and mesa issue.

It only happens with iris driver and gcc 10 with some specific flags and link time optimization enabled.

The issue should be fixed in Mesa 20.0.8 and 20.1.0, which were released about a week ago. I am pretty sure Ubuntu will backports the important fixes back to LTS soon, but I am also not sure why they didn't catch it in time during testing.

The workaround you are using will need to suffice for a moment.

Also it looks I forgot the one crucial package in the list of -dbgsym packages: libgl1-mesa-dri-dbgsym , if you install it the backtrace in the gdb should show more information now.

[posila]

...

Hey, thank you for helping out with troubleshooting.