What hardware do you have? Are you using d3d9 (via gallium-nine) or opengl? If gallium-nine, try opengl.

Do you get anything interesting in dmesg when this happens? Can you try an older version of mesa to see if it's a new issue? (Pretty sure DOTA2 *used* to work...)

Hardware: Primary Nvidia GTX 650, Secondary AMD HD 5750

Wine is from ppa:ubuntu-wine/ppa, so I'm not using gallium-nine.

(In reply to comment #2)
> Hardware: Primary Nvidia GTX 650, Secondary AMD HD 5750
> 
> Wine is from ppa:ubuntu-wine/ppa, so I'm not using gallium-nine.

Could you use a build of mesa that doesn't have the gallium-nine patches applied? And/or see if older versions of mesa work OK?

@Ilia Mirkin
I had a fresh, unused Kubuntu install on another partition, so I installed wine from ppa:ubuntu-wine/ppa and used the default Mesa version of Mesa 10.1.3. Dota 2 froze at the same point, after I selected a hero. Steam also gives a 
err:seh:setup_exception_record stack overflow 2128 bytes in thread 00ce eip 7bc5e05a esp 46c40ae0 stack 0x46c40000-0x46c41000-0x46d40000 

Another way to trigger this bug is by previewing an item from your armory or the store. Again this is with vanilla mesa with vanilla wine(no gallium-nine).

Could you try making an apitrace? Perhaps that would be enough to reproduce the error. Find a guide for how to use apitrace + wine, esp if you're on a 64-bit userspace.

Once you have the trace, try replaying it (glretrace). If glretrace also dies, then success. If not... more debugging.

Ilia,
Here is an apitrace:
https://drive.google.com/file/d/0B0IXTmvH5HZZZW0zRFRIQzV4a0U/edit?usp=sharing

Is there anything else I can do to help?

Aa a hint: Why dont you use the native Steam client? Dota2 is available there. If you can reproduce it there, we have at least spared one layer :)

@Tobias Klausmann
Good point! You are correct, it also crashes with the native port.

This all started from a similar stack overflow error when I was trying to play CS:GO which does not have a Linux port. I chose to report Dota 2, because it's free to play, so it would be easier for others to reproduce.

Simpler Steps to reproduce:
1. Install native Steam under Linux
2. Launch Dota 2
3. Start Bot match. Lock in a hero. OR preview an item in the store

Anything else I can do? Would another apitrace or Dota 2 mini dump help?

I tried to reproduce by replaying the trace, and I didn't get any crashes with 64-bit glretrace. My 32-bit setup is sadly still on mesa 9.2 or 10.0 or something, and was missing BaseVertex support, so I got a ton of errors. However also no hang. I'm going to build a fresh 32-bit install to see if I can reproduce.

Luke: Please confirm what issue you're seeing when doing a glretrace on the trace you supplied.

Mh, for me it does not hang, but crashes "back to desktop". (Native Linux Client)
Nothing in dmesg, just a Memory Access Violation error.

Intel works fine...so something odd in nouveau/gallium.

Debug result:
                                  
Program received signal SIGSEGV, Segmentation fault.                                                                
[Switching to Thread 0xde9afb40 (LWP 2840)]                                                                         
0xf4b639d6 in nv50_ir::Graph::Node::reachableBy(nv50_ir::Graph::Node const*, nv50_ir::Graph::Node const*) const () from /usr/lib/dri/nouveau_dri.so



Lets see if i can get the crashing shader out next...

Created attachment 105398 [details]
The Crashing shader

Ok, got the shader!

nouveau_compiler does not talk much sadly:

~/> ...
Compiling for NVC0
~/>

(In reply to comment #12)
> Created attachment 105398 [details]
> The Crashing shader
> 
> Ok, got the shader!
> 
> nouveau_compiler does not talk much sadly:
> 
> ~/> ...
> Compiling for NVC0
> ~/>

Parsing fails in nouveau_compiler... need to increase the size of the tokens array. However when compiling for NVE4 (and Luke has a Kepler), it goes into an infinite loop, which is consistent with a hang. Investigating...

Looks like it goes into an infinite recursion in findFirstUses, which is used for doing the texture barrier thing (which is done for kepler+). Ugh. Unfortunately I'm not 100% sure what the desired logic of this thing is... this might take a little while to untangle.

Created attachment 105404 [details] [review]
avoid infinite recursion in findFirstUses

Does the attached patch help? Should apply to approximately any version of mesa. It looks like it somehow ends up getting into a loop. Probably due to all the merging that ends up getting done during RA and manually modifying the ->defs (and uses?) lists. Not entirely sure though.

Mesa + avoid infinite recursion when finding first uses of tex patch successfully compiles now using nouveau_compiler, going to test it tomorrow i guess

For the patch:

Tested-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>
Reviewed-by: Tobias Klausmann <tobias.johannes.klausmann@mni.thm.de>

if that helps :)

Luke, can you confirm this?

Should be "fixed" in git. Thanks for reporting + testing.