I'm using Arch Linux x64 with Mesa 11.1.1 + lib32-Mesa 11.1.1 compiled from source with latest stable GCC and LLVM 3.7.1 (both normal and multilib). I have testing repositories enabled. No git packages are used, Linux is 4.4-zen.

What are the symptoms of the hang? If the GRID process still exists, does killing it restore a working desktop? Can you attach gdb to the GRID process and attach the output of "thread apply all bt full" when it hangs?

Can you try with "LC_ALL=C" instead of "LANG=C"? For me the latter did not work (http://steamcommunity.com/app/255220/discussions/0/558754260336036448/#c494631967654246615), while I can play the game correctly (and with quite good performance, BTW) with the former. I'm using a Radeon HD 7870 with almost git mesa.

(In reply to José Suárez from comment #3)
> Can you try with "LC_ALL=C" instead of "LANG=C"? For me the latter did not
> work
> (http://steamcommunity.com/app/255220/discussions/0/558754260336036448/
> #c494631967654246615), while I can play the game correctly (and with quite
> good performance, BTW) with the former. I'm using a Radeon HD 7870 with
> almost git mesa.

It worked. However, I've noticed some kind of a performance drop, but that doesn't actually matter, as the difference was about -5FPS.

(In reply to Michel Dänzer from comment #2)
> What are the symptoms of the hang? If the GRID process still exists, does
> killing it restore a working desktop? Can you attach gdb to the GRID process
> and attach the output of "thread apply all bt full" when it hangs?

Umm, the game doesn't hang the system. It's about the game's process not to respond at all - I can simply go to desktop and kill the process. I don't think that gdb attachment would help either, as the game is likely trying to load some files that it can't find, and then it hangs, so log would probably contain only "foo.bar: not found".

(In reply to Maxim Sheviakov from comment #5)
> (In reply to Michel Dänzer from comment #2)
> > What are the symptoms of the hang? If the GRID process still exists, does
> > killing it restore a working desktop? Can you attach gdb to the GRID process
> > and attach the output of "thread apply all bt full" when it hangs?
> 
> Umm, the game doesn't hang the system. It's about the game's process not to
> respond at all - I can simply go to desktop and kill the process. I don't
> think that gdb attachment would help either, as the game is likely trying to
> load some files that it can't find, and then it hangs, so log would probably
> contain only "foo.bar: not found".

For your information, Feral currently have a semi-open beta of Grid which among other things resolves the hang problem. In order to be able to access the beta you need to contact their customer support and they will give the key to you straight away.

I'm running plain vanilla, so I can't tell if it solves the problem you are reporting.

(In reply to Maxim Sheviakov from comment #5)
> Umm, the game doesn't hang the system. It's about the game's process not to
> respond at all - I can simply go to desktop and kill the process. I don't
> think that gdb attachment would help either, [...]

Of course it would; it would show us whether it's hanging in game code or driver code. From José's comments it sounds like it's likely the former though.

Okay. I will test it with a debugger + beta (if I'm lucky) one I complete my Gentoo setup.

(In reply to Michel Dänzer from comment #7)
> (In reply to Maxim Sheviakov from comment #5)
> > Umm, the game doesn't hang the system. It's about the game's process not to
> > respond at all - I can simply go to desktop and kill the process. I don't
> > think that gdb attachment would help either, [...]
> 
> Of course it would; it would show us whether it's hanging in game code or
> driver code. From José's comments it sounds like it's likely the former
> though.

This is the output: http://pastebin.com/ZVYp8HcQ

(In reply to Maxim Sheviakov from comment #9)
> This is the output: http://pastebin.com/ZVYp8HcQ

Please attach files here directly instead of referencing external sites.

After attaching to the process, please run "thread apply all bt full" at the gdb prompt to get the backtrace.

Created attachment 121779 [details]
Log from gdb

(In reply to Michel Dänzer from comment #10)
> Please attach files here directly instead of referencing external sites.
Okay, sorry.

> After attaching to the process, please run "thread apply all bt full" at the
> gdb prompt to get the backtrace.
Attaching the file, log collected with
~/> gdb > gdblog
%commands%

I also can't get native runtime working. After doing
> cd ~/.local/share/Steam/ubuntu12_32
> LD_LIBRARY_PATH=".:${LD_LIBRARY_PATH}" ldd $(file *|sed '/ELF/!d;s/:.*//g')|grep 'not found'|sort|uniq

I got the output containing
> libdbus-glib-1.so.2 => not found
> libgconf-2.so.4 => not found
> libnm-glib.so.4 => not found
> libnm-util.so.2 => not found
> libudev.so.0 => not found

Maybe that's an issue, but I don't think so - on my previous Archlinux installation the game wouldn't start with all those libraries present. Basically, my Linux installations' configurations were mostly the same.

There's no trace of the driver being involved in the hanging state. Based on that and José's comments, let's assume that this is a game bug.

(In reply to Michel Dänzer from comment #13)
> There's no trace of the driver being involved in the hanging state. Based on
> that and José's comments, let's assume that this is a game bug.

Damn, that's interesting. I will try to attach gdb to game running with that line in its Steam options and search for anything different.