[Mesa-dev] memory stomping in 95bd8a332d1 (dri: Move i965-specific context flag logic to dri common.)

Ilia Mirkin imirkin at alum.mit.edu
Thu Nov 28 20:27:44 PST 2013


Hi Eric,

I believe your commit 95bd8a332d1 might be the culprit of some crashes
I've seen. I had earlier identified a different commit via bisection,
but I believe it just happened to move some bits around that made the
memory stomping effects more noticeable.

On Thu, Nov 28, 2013 at 4:55 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
> On Thu, Nov 28, 2013 at 4:38 AM, Ilia Mirkin <imirkin at alum.mit.edu> wrote:
>> My reproducer is running glretrace on the portal.trace file that you
>> can obtain from https://bugs.freedesktop.org/show_bug.cgi?id=64323#c1.
>> I was not able to repro using random other traces I had sitting
>> around, so I'm guessing something in that trace is triggering the
>> erring functionality. The crashes always happen in
>> dri_destroy_context/st_destroy_context, but that doesn't mean that
>> trouble doesn't happen earlier on.

I've run it through valgrind. Here's what I see when running on nouveau (nv50):

==11501== Process terminating with default action of signal 11 (SIGSEGV)
==11501==  Bad permissions for mapped region at address 0x73CE1B1
==11501==    at 0x8AEDB81: driCreateContextAttribs (dri_util.c:446)
==11501==    by 0x7426903: dri2_create_context_attribs (dri2_glx.c:312)
==11501==    by 0x73E710F: glXCreateContextAttribsARB (create_context.c:78)
==11501==    by 0x546312: glws::createContext(glws::Visual const*,
glws::Context*, glws::Profile) (in /usr/bin/glretrace)
==11501==    by 0x503924: retrace_glXCreateContext(trace::Call&) (in
/usr/bin/glretrace)
==11501==    by 0x54423F: retrace::Retracer::retrace(trace::Call&) (in
/usr/bin/glretrace)
==11501==    by 0x408A9C: main (in /usr/bin/glretrace)

That line corresponds to

        ctx->Debug.DebugOutput = GL_TRUE;

which seems fairly innocuous. ctx comes from context->driverPrivate
however, which is claimed to be a gl_context. I tried following code
around, but at best it's either a dri_context or a dri2_context (which
has a glx_context base) in the gallium case, or I failed to follow the
code properly. Commenting out the whole chunk that modifies the
supposed-gl_context bits makes valgrind stop complaining about that
(it still has a different complaint somewhere in the teximage logic,
but I believe it's unrelated). I presume that's not a correct course
of action, of course, but I'm not sure what is.

To double-check, I went to my previous bisection result
(a3ed98f7aa85), and commented out the lines in question, and that
fixed everything as well, where it had been reliably segfaulting with
llvmpipe before.

Let me know if there's any additional information I can provide.

Thanks,

  -ilia


More information about the mesa-dev mailing list