Bug 83079 - [NVC0] Dota 2 (Linux native and Wine) crash with Nouveau Drivers
Summary: [NVC0] Dota 2 (Linux native and Wine) crash with Nouveau Drivers
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/nouveau (show other bugs)
Version: 10.1
Hardware: Other All
: medium normal
Assignee: Nouveau Project
QA Contact:
Depends on:
Reported: 2014-08-26 04:49 UTC by Luke
Modified: 2014-09-01 22:53 UTC (History)
0 users

See Also:
i915 platform:
i915 features:

The Crashing shader (23.26 KB, text/plain)
2014-08-29 00:09 UTC, Tobias Klausmann
avoid infinite recursion in findFirstUses (4.12 KB, patch)
2014-08-29 03:10 UTC, Ilia Mirkin
Details | Splinter Review

Description Luke 2014-08-26 04:49:58 UTC
Steps to reproduce:
1. Install Steam under Wine
2. Launch Dota 2
3. Start Bot match. Lock in a hero.
Expected Results:
Game starts

Actual Results:
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

tested with:
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.
Comment 1 Ilia Mirkin 2014-08-26 04:54:41 UTC
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...)
Comment 2 Luke 2014-08-26 07:56:52 UTC
Hardware: Primary Nvidia GTX 650, Secondary AMD HD 5750

Wine is from ppa:ubuntu-wine/ppa, so I'm not using gallium-nine.
Comment 3 Ilia Mirkin 2014-08-26 18:20:43 UTC
(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?
Comment 4 Luke 2014-08-26 20:02:22 UTC
@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).
Comment 5 Ilia Mirkin 2014-08-26 22:07:19 UTC
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.
Comment 6 Luke 2014-08-27 06:50:35 UTC
Here is an apitrace:

Is there anything else I can do to help?
Comment 7 Tobias Klausmann 2014-08-27 15:32:29 UTC
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 :)
Comment 8 Luke 2014-08-27 20:07:30 UTC
@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?
Comment 9 Ilia Mirkin 2014-08-27 20:37:37 UTC
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.
Comment 10 Tobias Klausmann 2014-08-28 01:19:02 UTC
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.
Comment 11 Tobias Klausmann 2014-08-28 17:59:05 UTC
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...
Comment 12 Tobias Klausmann 2014-08-29 00:09:27 UTC
Created attachment 105398 [details]
The Crashing shader

Ok, got the shader!

nouveau_compiler does not talk much sadly:

~/> ...
Compiling for NVC0
Comment 13 Ilia Mirkin 2014-08-29 01:48:40 UTC
(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...
Comment 14 Ilia Mirkin 2014-08-29 02:21:55 UTC
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.
Comment 15 Ilia Mirkin 2014-08-29 03:10:14 UTC
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.
Comment 16 Tobias Klausmann 2014-08-29 03:32:53 UTC
Mesa + avoid infinite recursion when finding first uses of tex patch successfully compiles now using nouveau_compiler, going to test it tomorrow i guess
Comment 17 Tobias Klausmann 2014-08-29 14:51:21 UTC
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?
Comment 18 Ilia Mirkin 2014-09-01 22:53:35 UTC
Should be "fixed" in git. Thanks for reporting + testing.

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.