Nouveau - Nov 2015 - [Bug 93004] New: Guild Wars 2 crash on nouveau DX11 cards

https://bugs.freedesktop.org/show_bug.cgi?id=93004

            Bug ID: 93004
           Summary: Guild Wars 2 crash on nouveau DX11 cards
           Product: Mesa
           Version: git
          Hardware: Other
                OS: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Drivers/DRI/nouveau
          Assignee: nouveau at lists.freedesktop.org
          Reporter: siro at das-labor.org
        QA Contact: nouveau at lists.freedesktop.org

Guild Wars 2 32bit crashes on DirectX 11 capable Nvidia cards using OpenGL and
Gallium Nine state tracker.
It doesn't crash on BARTS (AMD HD6850) and it doesn't crash on NV84
(Nvidia
Geforce 8600GT).

Bug reports:
https://bugs.winehq.org/show_bug.cgi?id=34342
https://github.com/iXit/Mesa-3D/issues/153

While this is referred as "Out of Memory" my guess is that the
GuildWars2 crash
reporter show wrong memory usage. Don't focus on that.

Using d3dretrace and valgrind I got this:
https://github.com/iXit/Mesa-3D/issues/153#issuecomment-157977989

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20151119/2d37ca6b/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=93004

--- Comment #1 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Where is the trace? Could you educate me on how to replay it myself?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20151119/cb162971/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=93004

--- Comment #2 from Patrick Rudolph <siro at das-labor.org> ---
Here's the trace (86MByte):
https://drive.google.com/file/d/0ByOfJQh38LRvSHk5YjgwdzVuRWc/view?usp=sharing

You need apitrace:
http://people.freedesktop.org/~jrfonseca/apitrace/

Run it using Gallium nine enabled wine:
wine ./apitrace-msvc/x86/bin/d3dretrace.exe Gw2.trace

To get the valgrind output I used:
valgrind -v --track-origins=yes --leak-check=full --trace-children=yes
--vex-iropt-register-updates=allregs-at-mem-access --workaround-gcc296-bugs=yes
wine ./apitrace-msvc/x86/bin/d3dretrace.exe Gw2.trace

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20151119/f9feffa8/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=93004

--- Comment #3 from Patrick Rudolph <siro at das-labor.org> ---
For the crash that occurs in nvc0_clear() I found it is likely a use after
free.
It accesses a pipe_resource that has been destroyed, but is still bound.
The correct behaviour of nine would be to call set_vertex_buffers(..., NULL)
first and then destroy the resource.
What does OpenGL on vertexbuffer destruction ?
Question is why does it work on other drivers, like R600 ?

For the second crash in nvc0_draw_vbo() I'm still investigating.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20151120/c2d9b0cc/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=93004

--- Comment #4 from Patrick Rudolph <siro at das-labor.org> ---
For the second crash I found I simple solution:
It crashes in nvc0_vbo.c:static void nvc0_validate_vertex_buffers_shared(struct
nvc0_context *nvc0), as buf is NULL:

396:    buf = nv04_resource(vb->buffer);
397:    offset = vb->buffer_offset;
398:    limit = buf->base.width0 - 1;

I'm not sure why it is possible to get to this point with a NULL vertex
buffer
and a NULL user_buffer. Nine seems to take care and only sets non NULL buffers.
For some reason nvc0->num_vtxbufs always includes an additional NULL vb...

I fixed this problem by adding:

396:    buf = nv04_resource(vb->buffer);
        if (!buf) continue;
397:    offset = vb->buffer_offset;
398:    limit = buf->base.width0 - 1;

With this fixed Guild Wars 2 doesn't crash in every pipe->draw_vbo.
I was able to play the game for a few minutes.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20151201/5385593a/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=93004

--- Comment #5 from Patrick Rudolph <siro at das-labor.org> ---
For the first crash when calling nvc0_clear(), it crashes here:
in file
nvc_context.c

in function
void nvc0_bufctx_fence(struct nvc0_context *nvc0, struct nouveau_bufctx
*bufctx, bool on_flush)

in line
403:    if (res)
404:        nvc0_resource_validate(res, (unsigned)ref->priv_data);

as the pipe_resource res is pointing to has been already freed.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20151203/ec86b40e/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=93004

--- Comment #6 from Ilia Mirkin <imirkin at alum.mit.edu> ---
    nvc0->dirty |= NVC0_NEW_ARRAYS;
    nouveau_bufctx_reset(nvc0->bufctx_3d, NVC0_BIND_VTX);

can you stick these 2 lines in under the if (!vb) section of
nvc0_set_vertex_buffers and see if that improves things? I need to think about
why those aren't already there... perhaps there's a reason. Doubtful
though.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20151203/a362ae39/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=93004

Ilia Mirkin <imirkin at alum.mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #7 from Ilia Mirkin <imirkin at alum.mit.edu> ---
Pushed this out as:

commit 432a798cf5c7fab18a3e32d4073840df7d0d37cb
Author: Patrick Rudolph <siro at das-labor.org>
Date:   Sun Dec 6 10:11:59 2015 +0100

    nv50,nvc0: fix use-after-free when vertex buffers are unbound

    Always reset the vertex bufctx to make sure there's no pointer to
    an already freed pipe_resource left after unbinding buffers.
    Fixes use after free crash in nvc0_bufctx_fence().

    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93004
    Signed-off-by: Patrick Rudolph <siro at das-labor.org>
    [imirkin: simplify nvc0 fix, apply to nv50]
    Signed-off-by: Ilia Mirkin <imirkin at alum.mit.edu>
    Cc: "11.0 11.1" <mesa-stable at lists.freedesktop.org>

I believe this should fix everything. Not sure why you didn't see issues
with a
G84... probably gets lucky somehow. Thanks for debugging it and tracking the
issue down!

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20151209/f1e5cbf5/attachment.html>