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).
Created attachment 123017 [details] glxinfo output
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?
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
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.
Created attachment 123135 [details] save game that crashes upon loading
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]
(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.
"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
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.
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.
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!
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.
Could "radeon/winsyses: sub-allocation for small buffers" help with this? https://patchwork.freedesktop.org/series/12382/
Yes, the series is meant for precisely this type of problem :) I plan to land it in the next days.
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.