Bug 94984 - XCom2 crashes with SIGSEGV on radeonsi
Summary: XCom2 crashes with SIGSEGV on radeonsi
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/Gallium/radeonsi (show other bugs)
Version: git
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Default DRI bug account
QA Contact: Default DRI bug account
Depends on:
Reported: 2016-04-17 20:00 UTC by kuehner.moritz
Modified: 2016-09-27 18:30 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

gdb backtrace (1.85 KB, text/plain)
2016-04-17 20:00 UTC, kuehner.moritz
glxinfo output (99.61 KB, text/plain)
2016-04-17 20:01 UTC, kuehner.moritz
save game that crashes upon loading (1006.82 KB, text/plain)
2016-04-21 21:18 UTC, kuehner.moritz

Description kuehner.moritz 2016-04-17 20:00:17 UTC
Created attachment 123016 [details]
gdb backtrace

At the start of a mission XCom2 crashes the moment when the drop solders of cut scene ends. It doesn't happen in all maps only in this one as far as I can tell.

I'm running Ubuntu 16.04 on an skylake CPU with a R9 380X. The crash happens with stock Ubuntu mesa (11.2) as well as with mesa git (git160414232200.eeff133) from padoka PPA.  

I tried to create a apitrace, but for some reason I can not get XCom2 to start with "apitrace trace" in front of it. Are there any apitrace ninja secrets to tracing steam games ;-)? (The game is 64bit so thats not the problem).
Comment 1 kuehner.moritz 2016-04-17 20:01:53 UTC
Created attachment 123017 [details]
glxinfo output
Comment 2 Nicolai Hähnle 2016-04-18 03:06:21 UTC
Hi Moritz, thanks for the report.

As for apitrace: In case you're running via Steam, consult this page: https://github.com/apitrace/apitrace/wiki/Steam - I've generally been successful with the instructions there.

As to the bug itself: The immediate reason for the crash seems apparent enough: we fail to map the buffer into which query results are written. That code needs to be hardened, and I've added that on my todo list.

However, we shouldn't fail that map in the first place. So an apitrace would indeed be helpful to understand better what's really going on here... do you have any other output from before the crash?
Comment 3 kuehner.moritz 2016-04-18 19:05:35 UTC
Hi Nicolai,

That link while informative did not help in this case. The game is 64bit and the wiki page is about debugging 32bit games on a AMD64 system. All my attempts to apitrace XCOM2 failed. Even injecting it directly into the wrapper script yielded a crash in XCOM at best. I actually contacted Feral support about it. Maybe I hear something back ;-).

I could upload the save game, it's only about 1MB. However XCOM saves are weird I'm not sure you would see the same map as I do and, of course, It assumes that you own the game.

Best Regards
Comment 4 Edwin Smith (Feral Interactive) 2016-04-21 13:04:51 UTC
Please make sure you attach the save game to the bug as this will help reproduction. 

Nicolai has a copy of XCOM 2 so should be able to debug this issue. This also sounds like a regression (I don't know if it is Mesa or a Feral update that caused the regression) as we have completed the entire game many, many times on Mesa and we know a lot of Linux users are also playing using Mesa.

Also if you attach the save game we can also assist if needed at a later date.
Comment 5 kuehner.moritz 2016-04-21 21:18:14 UTC
Created attachment 123135 [details]
save game that crashes upon loading
Comment 6 kuehner.moritz 2016-04-21 21:20:14 UTC
So I was able to continue the game over the point of the crash on may laptop and than save the game. This gives me a save game that crashes upon loading.

journald tells says this at the time of the crash:
OpenGL dispatch[7562]: segfault at 0 ip 00007fef119622ce sp 00007fee95ffa368 error 6 in libc-2.23.so[7fef117f0000+1c0000]
Comment 7 Edwin Smith (Feral Interactive) 2016-04-22 07:40:35 UTC
(In reply to kuehner.moritz from comment #6)
> So I was able to continue the game over the point of the crash on may laptop
> and than save the game. This gives me a save game that crashes upon loading.

For anyone testing please make sure you remove the .txt that might get added to the end of the save game when downloading. The save game file should be called "save498" and placed ins the follow path inside the games preference folder.

/VFS/Local/my\ games/XCOM2/XComGame/SaveData/save498

You can automatically open you preference folder using the button in the pre game launcher on the support tab.
Comment 8 Edwin Smith (Feral Interactive) 2016-04-22 09:02:31 UTC
"save498" (crash on load) testing results: 

Mac OS X - Success 
Linux 15.10 Nvidia 361.42 - Success
Linux 15.10 AMD Mesa 11.3-git1604150730.eeff13 - Crash on load
Comment 9 Nicolai Hähnle 2016-04-22 23:51:56 UTC
Unfortunately, I cannot reproduce the crash on my system. I can load the savegame and move around with some of the soldiers without a crash.

That said, _something_ weird is definitely going on. I was able to record an apitrace (by setting LD_PRELOAD="path to apitrace/build/wrapper/glxtrace.so" when starting Steam). The trace crashes very early when replayed. I'm investigating.
Comment 10 Nicolai Hähnle 2016-04-23 02:53:04 UTC
Okay, so that issue was an apitrace bug, see https://github.com/apitrace/apitrace/issues/450 if you're curious. I can now play back the trace.

Separately, I can reproduce the crash now after changing the graphics settings to maximum.
Comment 11 Nicolai Hähnle 2016-04-23 03:38:41 UTC
This is an instance of the bug where we run into the kernel-imposed limit of 64K mmaps, see also bug 94726. They're not necessarily GL buffer objects, as internal buffers can contribute as well. In any case, this is non-trivial to fix.

It seems like reducing the graphics quality might work around the problem in the meantime. There is also a potential workaround-patch attached to bug 94726, but it doesn't seem to actually work around the problem here.

Thanks Edwin for giving me access to a live game where this bug occurs, and thanks Moritz for reporting the bug in the first place!
Comment 12 Edwin Smith (Feral Interactive) 2016-04-25 08:30:06 UTC
Although XCOM 2 isn't supported on Mesa right now we'll see if we can get the game to limit the number of buffer objects it is using if it notices the system is getting close to the 64k limit as explained by Nicolai. 

We don't know how feasible this will be and the impact it will have on performance of XCOM 2 but given the driver side fix is none trivial we'll see if we can at least guard against the issue and avoid the user experiencing a SIGSEGV.
Comment 13 Ernst Sjöstrand 2016-09-22 11:23:15 UTC
Could "radeon/winsyses: sub-allocation for small buffers" help with this?
Comment 14 Nicolai Hähnle 2016-09-27 10:19:47 UTC
Yes, the series is meant for precisely this type of problem :) I plan to land it in the next days.
Comment 15 Nicolai Hähnle 2016-09-27 18:30:55 UTC
This should be fixed in master now. If it isn't, please check the backtrace and re-open if it's the same or a new bug report if it looks different.

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.