Bug 74689 - Calling glClear on a second surface renders without calling intel_prepare_render and can crash
Summary: Calling glClear on a second surface renders without calling intel_prepare_ren...
Status: VERIFIED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: unspecified
Hardware: Other All
: medium critical
Assignee: Ian Romanick
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-02-07 18:25 UTC by U. Artie Eoff
Modified: 2014-09-18 21:26 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments
weston-desktop-shell gdb backtrace (7.84 KB, text/plain)
2014-02-07 18:25 UTC, U. Artie Eoff
Details
weston log (5.84 KB, text/plain)
2014-02-07 18:26 UTC, U. Artie Eoff
Details
Small test case using GLX (4.36 KB, text/plain)
2014-02-13 16:24 UTC, Neil Roberts
Details

Note You need to log in before you can comment on or make changes to this bug.
Description U. Artie Eoff 2014-02-07 18:25:56 UTC
Created attachment 93626 [details]
weston-desktop-shell gdb backtrace

When using the "default" weston.ini included in the Weston source and "/usr/share/icons/hicolor/24x24/apps/google-chrome.png" does not exist, the weston-desktop-shell segfaults and Weston ends up with a "black" display.  See gdb backtrace for more info.

wayland (master) heads/master-0-ga18e344
drm (master) heads/master-0-g128e74c
mesa (master) heads/master-0-g5125165
libva (master) heads/master-0-gb4a4f9b
intel-driver (master) heads/master-0-g54cb60f
weston (master) heads/master-0-g7407345
Comment 1 U. Artie Eoff 2014-02-07 18:26:15 UTC
Created attachment 93627 [details]
weston log
Comment 2 U. Artie Eoff 2014-02-07 18:30:08 UTC
Update: Turns out it's not related to missing launcher icon files.  Rather, when the background-image for the desktop-shell does not exist, it segfaults.
Comment 3 U. Artie Eoff 2014-02-10 02:01:49 UTC
FWIW, this is not an issue with version 1.4.0
Comment 4 U. Artie Eoff 2014-02-10 02:06:20 UTC
(In reply to comment #3)
> FWIW, this is not an issue with version 1.4.0

errrr... not an issue with this stack, rather:

wayland (1.4) heads/1.4-0-gbab7f46
drm (master) libdrm-2.4.52-0-g46d451c
mesa (10.0) heads/10.0-0-g593484a
libva (master) libva-1.2.1-0-g88ed1eb
intel-driver (master) 1.2.2-0-g121e70d
weston (1.4) heads/1.4-0-g1afb238

Both aforementioned s/w stacks using cairo-glesv2 1.12.14
Comment 5 Neil Roberts 2014-02-12 15:30:00 UTC
I bumped into this issue when using Mesa master and had a dig around. I think it is related to the following Mesa commit although that isn't on the 10.0 branch so I'm not sure if I have exactly the same issue.

http://cgit.freedesktop.org/mesa/mesa/commit/?id=11baad35088dfd4bdabc1710df650

weston-desktop-shell creates at least two surfaces, one for the panel and one for the background. The panel surface gets painted first. When eglMakeCurrent is called for that the context's viewport will not have been set up yet so it will call intel_prepare_render on it as expected. After that it will try to paint the background surface and call eglMakeCurrent on that. The context's viewport will have already been configured at this point so it won't call intel_prepare_render. One of the things that intel_prepare_render does is call intel_update_renderbuffers which causes the size in the gl_framebuffer to be filled in. As this isn't called for the background surface the framebuffer's size remains at 0,0. If there is no background image then the only drawing operation that is done on the background surface is a glClear. However, _mesa_Clear bails out very early on if the size of the framebuffer is 0,0 so the call to glClear does nothing. Eventually eglSwapBuffers will be called on this surface but it still won't have a size. eglSwapBuffers ends up calling get_back_bo to ensure there is a back buffer. The size in the dri2_egl_surface is still -1,-1. intel_region_alloc doesn't cope with this and ends up crashing.

I'm not sure what the best thing to do it. Maybe we need to cause intel_prepare_render to be called at the start of _mesa_Clear?
Comment 6 Neil Roberts 2014-02-13 16:24:36 UTC
Created attachment 94009 [details]
Small test case using GLX

Here's a small test case using GLX to show that the problem isn't limited to Wayland.

This creates two windows, one red and one green. They are both painted just by calling glClear. The second window doesn't get painted at all, although it doesn't crash. It also seems to stop it from being able to redraw the first window more than once.
Comment 7 U. Artie Eoff 2014-02-14 03:11:43 UTC
Yes, Mesa seems to be the offending component here.  I tried Mesa 10.1 branch with Wayland/Weston 1.4.0 release and this issue shows up there too.  The 10.1 branch (along with master) includes the commit mentioned by Neil.
Comment 8 Neil Roberts 2014-02-14 12:43:53 UTC
I was thinking maybe the best thing to do would be to just remove the check for a zero-sized framebuffer entirely. This check also bails out if the scissor does not intersect with the framebuffer. However this can cause problems even without Kristian's patch in a contrived example. If the scissor is set to just outside the bounds of the framebuffer and then the framebuffer is resized to intersect with it before calling glClear, then _mesa_Clear won't yet have the new size so it will incorrectly skip out the clear entirely. I'm not sure whether it's a good idea though because there is nothing further down in the driver to bail out and it does end up putting a clear command in the batch buffer.
Comment 9 Neil Roberts 2014-04-04 13:06:34 UTC
I'm reassigning this bug to Mesa because it is reproducible with GLX and is not specific to Wayland.
Comment 10 Iago Toral 2014-04-07 09:07:10 UTC
This seems to be hitting the same problem raised by bug #74005. I attached a patch for that bug that also seems to fix this one.
Comment 11 Kristian Høgsberg 2014-04-29 22:04:59 UTC

*** This bug has been marked as a duplicate of bug 74005 ***


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.