Created attachment 93627 [details]
weston log

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.

FWIW, this is not an issue with version 1.4.0

(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

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?

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.

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.

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.

I'm reassigning this bug to Mesa because it is reproducible with GLX and is not specific to Wayland.

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.

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