Blender crashes in intel_batchbuffer_emit_reloc_fenced as soon as I move the cursor over the window. See bisect below. #0 intel_batchbuffer_emit_reloc_fenced (batch=0xadb1048, buffer=0x0, read_domains=2, write_domain=2, delta=0) at intel_batchbuffer.c:239 #1 0xb55856b5 in intelEmitCopyBlit (intel=0xad87428, cpp=<value optimized out>, src_pitch=1792, src_buffer=0xb10e328, src_offset=0, src_tiling=1, dst_pitch=1792, dst_buffer=0x0, dst_offset=0, dst_tiling=1, src_x=340, src_y=2, dst_x=340, dst_y=2, w=21, h=20, logic_op=5379) at intel_blit.c:177 #2 0xb559117a in intel_region_copy (intel=0xad87428, dst=0xb30b3f0, dst_offset=0, dstx=<value optimized out>, dsty=<value optimized out>, src=0xb10e390, src_offset=0, srcx=<value optimized out>, srcy=<value optimized out>, width=<value optimized out>, height=<value optimized out>, flip=0 '\000', logicop=5379) at intel_regions.c:397 #3 0xb5598b76 in do_blit_copypixels (ctx=0xad87428, srcx=340, srcy=977, width=21, height=20, destx=340, desty=977, type=6144) at intel_pixel_copy.c:179 #4 intelCopyPixels (ctx=0xad87428, srcx=340, srcy=977, width=21, height=20, destx=340, desty=977, type=6144) at intel_pixel_copy.c:206 #5 0xb5711b98 in _mesa_CopyPixels (srcx=340, srcy=977, width=21, height=20, type=6144) at main/drawpix.c:205 #6 0x082d9b0e in ?? () #7 0x082d9d45 in ui_block_flush_back () #8 0x082e2505 in ?? () ---Type <return> to continue, or q <return> to quit--- #9 0x082dd7db in uiDoBlocks () #10 0x081b1ef2 in screenmain () #11 0x081a6792 in main () If I use the commit before this one, the crash is gone, but none of the menus are drawn, so I guess it's only part of the problem. d449627829e1a4a3250a1a723af2f4e3cd5fd194 is the first bad commit commit d449627829e1a4a3250a1a723af2f4e3cd5fd194 Author: Kristian Høgsberg <krh@bitplanet.net> Date: Wed Feb 17 21:17:55 2010 -0500 intel: Implement the DRI2 invalidate function properly This uses a stamp mechanisms to mark the DRI drawable as invalid. Instead of immediately updating the buffers we just bump the drawable stamp and call out to DRI2GetBuffers "later". "Later" used to be at LOCK_HARDWARE time, and this patch brings back callouts at the points where we used to call LOCK_HARDWARE. A new function, intel_prepare_render(), is called where we used to call LOCK_HARDWARE, and if the buffers are invalid, we call out to DRI2GetBuffers there. This lets us invalidate buffers only when notified instead of on every glViewport() call. If the loader calls the DRI invalidate entrypoint, we disable viewport triggered buffer invalidation. Additionally, we can clean up the old viewport mechanism a bit, since we can just invalidate the buffers and not worry about reentrancy and whatnot. :040000 040000 5205e5b5764796a24b711eb741f34c2312e76d14 b5d71c3e0667eb5d0c1bb32f6f0c9b4dc9fc5aad M src System environment: -- chipset: G45 / ICH10R -- system architecture: 32-bit -- Linux distribution: Debian unstable -- Machine or mobo model: Asus P5Q-EM -- Display connector: DVI -- xf86-video-intel: 3d4b3f257fbbb69c6f236d9803abe54a90d7d434 -- xserver: 1.7.5.902 -- mesa: 449721a3d0082879c504b7a3b25cdf38c2293a85 -- drm: 04fd3872ee8bd8d5e2c27740508c67c2d51dbc11 -- kernel: 2.6.33
This commit on master (it's on the 7.8 branch as well) should fix the menu hover crash: commit 6422cf387baef75df9e5dbbed5cea4c0f495fe41 Author: Kristian Høgsberg <krh@bitplanet.net> Date: Mon Mar 22 17:54:35 2010 -0400 intel: Call intel_prepare_render() before looking up regions. Fixes #27213.
Confirmed, thanks for fixing this so quickly!
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.