Bug 97174

(In reply to blackheart_pro from comment #0)
> I got the suggestion that Mesa 13 was possibly too new for Ubuntu's stock

My apologies, I meant to say Mesa 12 here. Obviously, Mesa 13 would be too new for :P

For the reliably reproducible hangs: Can you record an apitrace and see if that reproduces the hang? Also, try running with GALLIUM_DDEBUG=1000 and provide the report from ~/ddebug_dumps/.

So I tried apitrace. Strangely, I can't get the hang to happen anymore when running apitrace. Mind you, this is a Steam app. I use the command:

DEBUGGER="apitrace trace" steam steam://rungameid/250110

to boot up the game and Steam, but I can't get the reliable hang to happen anymore with apitrace. Same when GALLIUM_DDEBUG=1000 (aside from slow performance when doing this, but I assume this is normal because it's some sort of debug environment, right?) When I run the game directly from the Steam client and use the steps I described to produce the hang, the hang happens. heh. I'm not sure what's happening.

Hi, I can't seem to reproduce any freezes with AAC here (R9 380X, Gentoo, Mesa 6db93cd, LLVM r276989). I do see some reproducible stutter when getting to certain parts of the game for the first time after starting it, but that lasts for less than a second - is that what you are talking about? (I don't get it when going back to the start screen, so probably not)

Does the game only temporarily freeze and then continue, does it freeze permanently or does the whole system lock up? If (only) the game remains frozen, you can use the following command to see where it is stuck (you may need to install gdb first):

 gdb --pid `pidof cactus.x86_64` --batch -ex 'info threads' -ex 'thread apply all bt'

Btw, the game also has a free demo on Steam - look for the Download Demo button on http://store.steampowered.com/app/250110/ - but afaik that is quite a bit older than the full version now so it may or may not have the same issue.

Strange that you don't get a hang with apitrace. For the hang not happening with the GALLIUM_DDEBUG setting, there are two possible explanations:

1. It might be a timing thing. With very recent Mesa you can try GALLIUM_DDEBUG="pipelined 1000" instead, which should run at higher performance. If that hangs, the resulting report should be just as good.

2. It might be that the hangs depend on not flushing. You can run GALLIUM_DDEBUG="1000 noflush", which doesn't affect the flushing behaviour. It would be interesting to know if that still hangs, though unfortunately the hang reports tend to be less useful.

The conclusion I'm coming to is it's almost certainly some kind of conflict with Steam; particularly when launching the game through Steam itself. AAC is DRM free, it doesn't need Steam to run. When I run the game without Steam, I don't get any hangs at all. That's probably why I can't produce the hang when running the command mentioned in comment 3. Using apitrace with that command, I don't believe it launches the game with the full Steam environment. Steam doesn't appear to be running in the background and I can't shift+tab to get the overlay. I can't properly record the hang without Steam present, but I'm not sure how (or if i even can,) use apitrace + ACC with full Steam running as if launched through the client. This also applies to GALLIUM_DDEBUG=1000 as well. No hangs and it doesn't produce any files (they're supposed to appear in /ddebug_dumps/ in the home folder, correct?)

 (In reply to Daniel Scharrer from comment #4)
> Does the game only temporarily freeze and then continue, does it freeze permanently or does the whole system lock up? 

Permanent. Only the game freezes. I can't even kill it when it does freeze, I've tried everything. Strange that you aren't getting it. Are you using Mesa 12? That's the key here, Mesa 11 series doesn't suffer from this bug at all. 

> you can use the following command to see where it is stuck (you may need to install gdb first):

>gdb --pid `pidof cactus.x86_64` --batch -ex 'info threads' -ex 'thread apply all bt'

gdb is installed by default in Ubuntu 16.04, but seems I can't get this command to work.

If you have DRI3 enabled, does setting the environment variable LIBGL_DRI3_DISABLE=1 when launching steam avoid the hang? If so, how about LD_PRELOAD='/usr/$LIB/libxcb.so.1':$LD_PRELOAD ?

(In reply to Michel Dänzer from comment #7)
> If you have DRI3 enabled, does setting the environment variable LIBGL_DRI3_DISABLE=1 when launching steam avoid the hang? If so, how about LD_PRELOAD='/usr/$LIB/libxcb.so.1':$LD_PRELOAD ?

Looks like both of these work. no hanging when launching AAC through Steam and performing the usual steps.

The problem is caused by the Steam runtime shipping an old version of libxcb, which has a bug causing DRI3 apps to hang randomly.

Oooh, that makes sense. Steam is the culprit, as suspected. Thanks, Michel Dänzer! Looks like this is on Valve. Guess I should contact them.

*** Bug 97428 has been marked as a duplicate of this bug. ***

*** Bug 98705 has been marked as a duplicate of this bug. ***

https://github.com/ValveSoftware/steam-for-linux/issues/4638