Bug 24185 - [G45] Blender: crash in brw_prepare_vertices after "Render this window"
[G45] Blender: crash in brw_prepare_vertices after "Render this window"
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965
Other All
: high critical
Assigned To: Brian Paul
: regression
Depends on:
  Show dependency treegraph
Reported: 2009-09-27 15:24 UTC by Sven Arvidsson
Modified: 2009-10-07 13:09 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:

blender backtrace (2.97 KB, text/plain)
2009-09-27 15:24 UTC, Sven Arvidsson
render this window button (5.66 KB, image/png)
2009-09-27 15:24 UTC, Sven Arvidsson

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Arvidsson 2009-09-27 15:24:33 UTC
Created attachment 29908 [details]
blender backtrace

Blender will crash after the "Render this window" button is pressed. See attached screenshot to find the button.

System environment:
-- chipset: G45 / ICH10R
-- system architecture: 32-bit
-- Linux distribution: Debian unstable
-- Machine or mobo model: Asus P5Q-EM
-- Display connector: DVI
-- KMS: enabled
-- xf86-video-intel: efbcf29dd1a1ca058b7a2a93f0685102c06c9369
-- xserver:
-- mesa: ecf3091cc78638919f1977ccc0307c51b6731385
-- drm: 67e4172394a88d4922fb8d9c7c3d96ce7e02c5a6
-- kernel: 2.6.31
Comment 1 Sven Arvidsson 2009-09-27 15:24:55 UTC
Created attachment 29909 [details]
render this window button
Comment 2 fangxun 2009-09-28 04:00:45 UTC
This issue can be reproduced on G45, 945GM, 945GME and 965GM.
Comment 3 Sven Arvidsson 2009-09-28 13:00:38 UTC
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
Comment 4 Wolfgang Kufner 2009-09-29 03:49:44 UTC
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
Comment 5 Wolfgang Kufner 2009-09-29 04:02:32 UTC
I get the exact same symptoms with:
  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
Comment 6 Sven Arvidsson 2009-09-29 07:08:56 UTC
(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.

Comment 7 martin 2009-09-30 10:30:02 UTC
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:

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]

Comment 8 Eric Anholt 2009-10-07 12:06:02 UTC
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?
Comment 9 Brian Paul 2009-10-07 12:49:53 UTC
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.
Comment 10 Brian Paul 2009-10-07 13:09:55 UTC
OK, fixed on the 7.6 branch with commit 7dd2c0afd68a90bb6b1f5f030c8d60bf6a562071