Cataclysm-dda: Fails to start with segfault and error: "Failed to map mcs buffer into GTT"

[zer0Entropy]

I just unzipped a fresh "install" of version 6538 (filename "cataclysmdda-0.C-6538.tar.gz", tiles version) on Ubuntu Linux. Trying to run both cataclysm-launcher and catacylsm-tiles gives me the following output:

libpng warning: iCCP: known incorrect sRGB profile
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Failed to map mcs buffer into GTT
Segmentation fault (core dumped)

The "stable" version of 0.C runs just fine with no warnings or errors.
Am I the first one to run into this bug? I searched both Google and GitHub and couldn't find any relevant results. Is there anything I can do to try to fix this on my end?

[AbandonedCode]

I cannot seem to find your build, Narc.ro's Jenkins is behind and frontpage serves me 6530.

Can you build from latest experimental's source? you may get better results if you compile CDDA yourself.

[Treah]

Looking online this looks like an error from the MESA drivers in linux. I suspect this has something to do with the SDL lib being used to compile and the one that is present in the distro that your using. Like AbandonedCode said building from source will likely fix this problem.

[fernzi]

This is also happening to me with a package built from source on the OpenSUSE Build Service.

I suspect it's related to Intel graphics, since I had been running C:DDA on another computer with Radeon graphics, using the same package, and it worked just fine.

[monsieurh]

Same issue here with intel graphics too. Works fine on other systems. Tryed to compile with GCC and CLANG to no avail.

[Treah]

I have a macbook air with intel 5000 graphics I normally don't compile with tiles tho so I haven't seen this problem. Ill do another compile tonight with tiles and report if I get this problem.

[0xFireball]

I too am experiencing this problem.

I'm running Manjaro Linux with Intel graphics, and my output is pretty much what @zer0Entropy got when I run cataclysm-tiles.

[Treah]

I am unable to confirm this.. I was able to build the game just fine and launch it. I do get the same error "libpng warning: iCCP: known incorrect sRGB profile however I only get the error once when launching, and the game runs fine.

My system is using the following on a arch build.
libpng16.so.16.30.0
gcc version 7.1.1

System type is x86_64
Video driver.
Intel Corporation Haswell-ULT Integrated Graphics Controller [8086:0a26] (rev 09)

[0xFireball]

What information can we share that will be helpful for diagnosing the problem? @Treah

[Treah]

Same information that I provided above would be helpful. It could be a problem with a older version of the libpng or something deeper. Also what version of the game are you guys using and have you tried to compile from the latest git pull?

[monsieurh]

Compiled from git latest pull as of yesterday 17:00 UTC. FWIW I tried to compile with clang as well.

[0xFireball]

Yes, I was using the latest git pull yesterday. As for library versions, I'm using those provided by my distribution.

[0xFireball]

Well I have 2 laptops, and it's working fine on one with this configuration (my other laptop has the issue and I will provide the information later today), building from CDDA git.

Manjaro Linux

gcc v7.1.1

video driver: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09) (prog-if 00 [VGA controller])

x86_64

libpng: libpng16.so.16.29.0

Also of interest: I'm not getting any errors about failed to map mcs buffer into GTT, while I _am_ getting that error on the other system before segfaulting.

However, I am getting the libpng warning.

On the computer with the issue, an older version of CDDA Tiles works fine, but the version from git is segfaulting with the failed to map buffer error message.

[0xFireball]

Here's the information with the computer with the issue:

Manjaro Linux

x86_64 system, gcc v7.1.1, and libpng16.so.16.29.0

video driver: Intel Corporation HD Graphics 520 (rev 07) (prog-if 00 [VGA controller])

this system is very similar to my other system (previous comment) in terms of libraries, except the hardware and video driver are different. Also the map buffer error only shows up on this system where it segfaults.

[monsieurh]

Adding information as well :
Linux 4.11.9-1-ARCH
libpng 1.6.30-1
gcc (GCC) 7.1.1 20170528
Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2)
mesa 17.1.4-1
The common factor seems to be the driver...

[0xFireball]

it looks like both of us are having a problem with something related to the Intel HD graphics 520.

[fernzi]

It seems to affect Skylake and later, since my versions are pretty much the same except for the more recent Kaby Lake chip:

Linux 4.11.8-1-default
libpng 1.6.30
gcc (SUSE Linux) 7.1.1 20170629
Mesa DRI Intel(R) HD Graphics 620 (Kaby Lake GT2)
Mesa 17.1.4

[0xFireball]

Just in case anyone wants to play CDDA git while we resolve this issue, I've been playing the windows CI builds in Wine, and it works well enough for now.

[Treah]

Looks like there has been a SDL update. My arch system pulled down a new version of it so this may have been a larger issue with that lib causing the error. If possible try grabbing the newest SDL libs and see if the problem has been resolved.

[monsieurh]

Can you precise the version of SDL you now have ?

[fernzi]

There hasn't been a new stable release of SDL since october 2016 (2.0.5), you probably just got a rebuild, which happens in Arch every time something like libc gets updated.

For reference, I just rebuilt C:DDA on OpenSUSE Tumbleweed, which has the same SDL version, and I'm still getting the same error.

[CHmSID]

I can also confirm on Manjaro
4.9.35-1-MANJARO
Mesa DRI Intel(R) HD Graphics 530 (Skylake GT2)
mesa 17.1.4-1

I can get into the game through bumblebee/primusrun using GTX1060. If you then enable software rendering in options under Graphics the game will launch properly using Intel GPU.

[Treah]

@franzzapata Yes your correct the version that I have is just a rebuild from the glibc update. However this is likely a problem with the MESA drivers when they are interacting with the specific hardware that you guys have. Again this bug is hardware dependent so its not likely a problem with the game itself but rather with a driver in Linux that has a problem. This really needs to be direct up that way as its unlikely the issue will be resolved in CDDA. I know you guys have mentioned .C works ok but there has been a great deal of changes to the code base since that release so its not a good benchmark to go from. A better one if you still suspect this is a problem with the game is to walk back the commit changes and find the last version that this worked on. As I don't have the hardware you have there is no way for me to do any type of testing / troubleshooting, my Intel graphics on this mac-air is from 2012 :(

Also this might be of intrest.... looks like skylake and later have some problems.

http://www.zdnet.com/article/debian-linux-reveals-intel-skylake-kaby-lake-processors-have-broken-hyper-threading/

[monsieurh]

Thanks for the update. Anyway to force software rendering using a config file or something ? Could be a workaround for now...

[fernzi]

@Treah The specific commit could be found with a bisect, but as you mention, the last known working version is 0.C and, even with bisect, finding the bug could be very time consuming. Personally, I would only be able to work on it every now and then, so if anyone with more time to spare (and a skylake processor) is willing to do the bisect/compile/test process, it'd be very appreciated.

@monsieurh The config file on Linux is usually on ~/.cataclysm-dda/options.json or ~/.config/cataclysm-dda/options.json. If you can't find it, running the text version of the game also creates it.

[monsieurh]

@franzzapata good to know about the bisect thing. I'll try to take some time to check it out.

About the config file, however, I can't find the option to turn on software rendering. Is there any page on the wiki or else documenting the available options ?

[fernzi]

@monsieurh I'm not sure I've ever seen any docs about the options, but I checked the config file in one of my backups, and the option should look like this:

{
  "info": "Use software renderer instead of graphics card acceleration.",
  "default": "Default: False",
  "name": "SOFTWARE_RENDERING",
  "value": "true"
},

[Night-Pryanik]

Need to mention that this option is available only on SDL builds.

[kevingranade]

There is no option on non-sdl builds because there is no hardware
integration to disable, its always, "software rendered".

[Treah]

Need to mention that this option is available only on SDL builds.

This is assumed since the non-tiles version does not have this problem. This is only a error when dealing with SDL and MESA drivers along with the intel HD graphics and possibly bug.

[monsieurh]

I confirm that @franzzapata 's workaround using theoption.json file is working fine.

[Coolthulhu]

Would it be possible to have a try-catch that sets software rendering on initialization failure or it a kind of error that has to crash the process?

On a side note, it may be a good idea to default software rendering to true. It's safer and often faster than hardware - on my setup 3 times faster.

[mutability]

This is probably the same as #19285 reported almost a year ago. At the time it looked like the cause was CDDA creating too many tiny textures. CDDA should avoid doing that.

You could maybe look at my old SDL_gpu branch as a starting point, as that branch did not suffer from this bug.

[mutability]

@Coolthulhu It is a segfault deep in the bowels of the Intel driver. I doubt you can recover from that cleanly.

[Treah]

I still suspect this problem is due to the hardware bug in these processors. I would try the microcode update from Intel and see if it resolves the problem.

[mutability]

It is highly unlikely that this is an intermittent HT-related problem, since it is 100% reproducible and fails in the Intel _graphics_ driver.

Also, this fails for me on a system with microcode more recent than the one quoted in the article linked above.

[BrettDong]

It is a segfault deep in the bowels of the Intel driver

Has this problem been reported to the upstream?

[mutability]

Not reported by me; I didn't spend much time digging into it since it didn't occur post-SDL_gpu changes which is what I was interested at the time, and subsequently I stopped working on everything CDDA-related. It is possible that it's a bug in SDL rather than a bug in the driver.

If someone else wants to chase down the right upstream place to report it to, I can provide hardware/software details - let me know what info you need.

[mutability]

Also it's probably worth noting that, crash aside, the Intel driver appears to be hitting a limit on the number of textures it can support. If that's the case then CDDA's not going to _work_ even with the crash fixed, so this needs attention on the CDDA side to reduce the number of textures used.

[Leland]

Should have been fixed by #22820. Ping me to reopen if not, or create a new issue for visibility's sake.