<div dir="ltr">(CC'ing Mesa-dev since this is a Mesa bug).<br><div><br>On 16 September 2013 11:00, Chad Versace <span dir="ltr"><<a href="mailto:chad.versace@linux.intel.com" target="_blank">chad.versace@linux.intel.com</a>></span> wrote:<br>
<div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">CC'ing Piglit.<div><div class="h5"><br>
<br>
On 09/14/2013 08:54 AM, Paul Berry wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I'm investigating a failure in spec/OES_fixed_point/<u></u>attribute-arrays,<br>
specifically the command line<br>
"/home/pberry/.platform/<u></u>piglit-mesa/piglit/build/bin/<u></u>oes_fixed_point-attribute-<u></u>arrays<br>
-auto -fbo".  It's segfaulting during piglit/waffle initialization due to<br>
Mesa accessing freed memory.  This only started happening for me recently,<br>
however I suspect that's because the access to freed memory makes it a<br>
heisenbug, and the root cause has probably been around for a long time.<br>
<br>
What's interesting about this test is that it's a GLES1 test being run in<br>
-fbo mode, which means that piglit first starts initializing things<br>
assuming it's going to run the test with fbo's, then at some point it<br>
figures out that it can't (because fbo's are unsupported), so it tears down<br>
its configuration and starts a new configuration to test using a window.<br>
<br>
While establishing the new configuration, waffle calls eglMakeCurrent().<br>
Deep in the bowels of Mesa's implementation of this function, it decides<br>
that it needs to flush the context that was previously current.  But that<br>
context refers to data structures that were freed when piglit tore down its<br>
old configuration (specifically, it refers to brw->bufmgr, which was freed<br>
in response to a call to eglTerminate()).<br>
<br>
I've been studying the egl calls made by piglit/waffle during this test and<br>
I believe they look like this (I may be missing a few but I think I found<br>
most of them):<br>
<br>
Initial setup:<br>
- eglGetDisplay()<br>
- eglInitialize() (causes intel_init_bufmgr() to be called, which creates<br>
bufmgr 1)<br>
- eglQueryString()<br>
- eglChooseConfig()<br>
- eglBindAPI()<br>
- eglCreateContext() (causes brwCreateContext() to be called, which creates<br>
context 1)<br>
- eglGetConfigAttrib()<br>
- eglCreateWindowSurface()<br>
- eglMakeCurrent()<br>
Initial teardown:<br>
- eglDestroySurface()<br>
- eglDestroyContext() (interestingly, does not cause intelDestroyContext to<br>
be called, perhaps because the context is still current?)<br>
- eglTerminate() (causes intelDestroyScreen() to be called, which frees<br>
bufmgr 1)<br>
Second setup:<br>
- eglGetDisplay()<br>
- eglInitialize() (causes intel_init_bufmgr() to be called, which creates<br>
bufmgr 2)<br>
- eglQueryString()<br>
- eglChooseConfig()<br>
- eglBindAPI()<br>
- eglCreateContext() (causes brwCreateContext() to be called, which creates<br>
context 2)<br>
- eglGetConfigAttrib()<br>
- eglCreateWindowSurface()<br>
- eglMakeCurrent() (at this point Mesa tries to flush context 1, which<br>
causes a segfault beause this causes it to try to access bufmgr 1, which<br>
has already been freed)<br>
<br>
So, my questions are:<br>
- Does it look like piglit/waffle is making an allowed sequence of EGL<br>
calls?  (In other words, is the bug in Mesa or piglit/waffle?)<br>
- If the bug is in Mesa, what should be happening instead?  I assume that<br>
at some point Mesa should have made the current context non-current (and<br>
destroyed it, perhaps), but I'm not sure when that should have happened,<br>
nor what code should have been responsible for doing it.<br>
<br>
Thanks in advance, Chad.  I hope you're enjoying your business travel!<br>
</blockquote>
<br></div></div>
The sequence of EGL calls is legal. The bug is in Mesa. After discovering<br>
the bug many months ago, I posted a test to the Piglit list, but it was<br>
ignored and then forgotten. (Gerrit please!) I'll repost the test in the<br>
next day or so after rebasing it.<br>
<br>
See the comments [1] in my test to see why the sequence of EGL calls is legal.<br>
<br>
[1] <a href="http://cgit.freedesktop.org/~chadversary/piglit/tree/tests/egl/spec/egl-1.4/egl-terminate-then-unbind-context.c?h=egl-terminate-then-unbind#n26" target="_blank">http://cgit.freedesktop.org/~<u></u>chadversary/piglit/tree/tests/<u></u>egl/spec/egl-1.4/egl-<u></u>terminate-then-unbind-context.<u></u>c?h=egl-terminate-then-unbind#<u></u>n26</a><br>

<br>
If I correctly understand the EGL spec quote above, the call to eglMakeCurrent that currently<br>
segfaults should instead flush the queued-to-be-destroyed context and then promptly destroy it.<br>
</blockquote></div><br></div><div class="gmail_extra">Yeah, after consulation with ajax on IRC I agree.  In point of fact, this is what eglMakeCurrent is trying to do--it's just not succeeding because the act of flushing the context causes it to refer to the already-freed bufmgr.<br>
<br></div><div class="gmail_extra">It sounds like what we need to do in Mesa is add some sort of mechanism to make sure eglTerminate() doesn't destroy the bufmgr until after the context using it is no longer current (e.g. reference counting).<br>
</div></div></div>