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 <imir...@alum.mit.edu> wrote: > On Thu, Nov 28, 2013 at 4:38 AM, Ilia Mirkin <imir...@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 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
