Bug 24185

Created attachment 29909 [details]
render this window button

This issue can be reproduced on G45, 945GM, 945GME and 965GM.

f5539b6991e336aa1cf302dbdb1a29b3e85cff36 is the first bad commit
commit f5539b6991e336aa1cf302dbdb1a29b3e85cff36
Author: Xiang, Haihao <haihao.xiang@intel.com>
Date:   Thu Aug 20 18:19:36 2009 +0800

    i965: validate sf state

:040000 040000 9bcff867d0a3adf6e2c39bc23db5e60aef174086 ef44496a8b0340ce4281b8dd683fe8aa6e0f330a M	src

I can press the "Render this window" button as often as I like. No problem. But if I then close the resulting render window (with the window manager close button) then it crashes every time.

so here, Mobile 4 [8086:2a42] (rev 07) to reproduce:
open blender
press "Render this window" button
close the resulting render window with its close button
 

I get the exact same symptoms with:
libgl1-mesa-dri:
  Installed: 7.6.0~git20090928.6829ef74-0ubuntu1~xup~1
which I am currently testing because it is supposed to be included in ubuntu 9.10

(In reply to comment #4)
> I can press the "Render this window" button as often as I like. No problem. But
> if I then close the resulting render window (with the window manager close
> button) then it crashes every time.

Yes, it's the same behaviour for me. Sorry if my first explanation wasn't clear enough.

I could also repro this bug on my G45 using karmic and the mesa version from the X-Updates repository. I added dmesg, xorglog etc do this downstream bug:
https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/439488

When Blender crashes I see this in dmesg:

[  101.175856] [drm] TMDS-12: set mode 800x600 24
[  170.763240] [drm:i915_gem_object_pin_and_relocate] *ERROR* Relocation beyond target object bounds: obj ffff8801fc989900 target 219 delta 131072 size 131072.
[  170.763245] [drm:i915_gem_execbuffer] *ERROR* Failed to pin buffers -22
[  188.451656] [drm] TMDS-12: set mode 1680x1050 25
[  229.623952] blender-bin[2133]: segfault at 0 ip 00007f75455a64f5 sp 00007fffe2c2be38 error 4 in libc-2.10.1.so[7f7545524000+166000]

http://launchpadlibrarian.net/32752843/dmesg_after_blender_render_this_window_crash.txt
http://launchpadlibrarian.net/32752859/Xorg.0.log
http://launchpadlibrarian.net/32752937/dri_debug.tgz

That bisect appears to be wrong -- I get the same failure in the previous commit.  Things in fact fail in various ways back to the Mesa metaops introduction.  It looks like the problem is that in this path:

Breakpoint 2, _mesa_meta_free (ctx=0x9a625a0) at drivers/common/meta.c:305
305	{
(gdb) bt
#0  _mesa_meta_free (ctx=0x9a625a0) at drivers/common/meta.c:305
#1  0xb5db018d in intelDestroyContext (driContextPriv=0x99b8990)
    at intel_context.c:821
#2  0xb5da7e6f in driDestroyContext (pcp=0x99b8990) at ../common/dri_util.c:545
...

(gdb) call _mesa_get_current_context()
$41 = (GLcontext *) 0x8edaa40
(gdb) p ctx
$42 = (GLcontext *) 0x9a625a0

so we're trying to free objects from ctx when _mesa_get_current_context() is what will be used when looking up the names to get objects to free.  Later on down the line, we get a _mesa_error when binding a vertex array object for a drawpixels, state gets stomped since we don't catch that that happened, and finally when we get to the clear things are just hosed.

Not really sure what the right answer is here, but I suspect it's for _mesa_meta_free to only happen from the context data free path.  Brian, any opinion?

Strictly speaking, we shouldn't have to worry about freeing any of the textures, VBOs, etc. in _mesa_meta_free(); I was just being paranoid.

I'll do a mem leak check with valgrind and remove this code if I can...

Otherwise, checking  if (ctx == _mesa_get_current_context())  is another way to fix this.

OK, fixed on the 7.6 branch with commit 7dd2c0afd68a90bb6b1f5f030c8d60bf6a562071