Steps to reproduce:
1. Install Steam under Wine
2. Launch Dota 2
3. Start Bot match. Lock in a hero.
Dota 2 will freeze with the following error in the Wine terminal:
err:seh:setup_exception_record stack overflow 2160 bytes in thread 008b eip 7bc5e05a esp 47cb0ac0 stack 0x47cb0000-0x47cb1000-0x47db0000
OpenGL version string: 3.0 Mesa 10.4.0-devel (git-83503f9 2014-08-25 trusty-oibaf-ppa+gallium-nine)
Note if I reboot with the Nvidia proprietary drivers, Dota 2 runs flawlessly under Wine. Dota 2 also works under Wine with AMD catalyst drivers.
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?
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.
Here is an apitrace:
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 :)
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.
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 <firstname.lastname@example.org>
Reviewed-by: Tobias Klausmann <email@example.com>
if that helps :)
Luke, can you confirm this?
Should be "fixed" in git. Thanks for reporting + testing.
on Feb 28, 2017 at 05:30:29.
(provided by the Example extension).