|Summary:||[NVC0] Dota 2 (Linux native and Wine) crash with Nouveau Drivers|
|Component:||Drivers/DRI/nouveau||Assignee:||Nouveau Project <nouveau>|
|Status:||RESOLVED FIXED||QA Contact:|
|i915 platform:||i915 features:|
The Crashing shader
avoid infinite recursion in findFirstUses
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: wine-1.7.24 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
Ilia, Here is an apitrace: https://drive.google.com/file/d/0B0IXTmvH5HZZZW0zRFRIQzV4a0U/edit?usp=sharing 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 <email@example.com> Reviewed-by: Tobias Klausmann <firstname.lastname@example.org> 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.