<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - Segfault in pushbuf_kref when running the android emulator (qemu) on nv50" href="https://bugs.freedesktop.org/show_bug.cgi?id=92438#c23">Comment # 23</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - Segfault in pushbuf_kref when running the android emulator (qemu) on nv50" href="https://bugs.freedesktop.org/show_bug.cgi?id=92438">bug 92438</a> from <a class="email" href="mailto:imirkin@alum.mit.edu" title="Ilia Mirkin <imirkin@alum.mit.edu>"> Ilia Mirkin</a> <pre>(In reply to Jim Blandy from <a href="show_bug.cgi?id=92438#c21">comment #21</a>) > I have no idea what this code is supposed to be doing, but here's what I can > infer: > > The call to pushbuf_kref crashes because the `struct nouveau_bo *bo` > argument is NULL, and cli_push_get tries to use it. The caller of > pushbuf_kref, pushbuf_validate, is iterating over a list of brefs; the > current bref's bo field is NULL. > > This bref was created by nouveau_bufctx_refn, which was passed a NULL `bo` > argument. Its caller is nvc0_add_resident, which was passed a `struct > nv04_resource *` whose `bo` field is NULL. > > This nv04_resource was created by a call to nouveau_buffer_create in which > buffer->domain is never set to anything other than 0. Looking at > nouveau_buffer_allocate, it seems like a domain of zero is a legitimate > value; the last branch of the if-else chain asserts that this is the case. > Since that path doesn't set buf->bo, it seems it's legitimate for buf->bo to > be NULL. > > pushbuf_kref seems adamant that bo should be non-NULL; both cli_push_get and > cli_kref_get require it. At this point I'm lost: should nouveau_bufctx_refn > never be passed a NULL bo? Should such a bufref never make it onto the list > that pushbuf_validate sees? I'm not sure. > > Here's the stack trace at the call to nouveau_bufctx_refn: > > #0 nouveau_bufctx_refn (bctx=0x555555b3eea0, bin=bin@entry=1, bo=0x0, > flags=256) at bufctx.c:126 > #1 0x00007ffff0c33154 in nvc0_add_resident (flags=256, res=0x555555bf4800, > bin=1, bufctx=<optimized out>) at nvc0/nvc0_winsys.h:29 > #2 nvc0_validate_vertex_buffers_shared (nvc0=0x555555b3cf30) at > nvc0/nvc0_vbo.c:407 Whoa, great analysis! And makes a *ton* more sense than my thought, which was that the GPU hung and we ran out of GEM handles making pushbufs. So this is one of those idiotic bo-less resources. Ugh. Will check if your repro makes it happen for me too.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>