GNOME Bugzilla – Bug 770387
[Wayland] mutter crashes with fatal error "Could not import pending buffer, ignoring commit"
Last modified: 2016-10-10 13:02:59 UTC
Created attachment 334137 [details] bt full Summary: Typing a string in gedit's search field in the open file popup, mutter/gnome-shell crashes with: Could not import pending buffer, ignoring commit How reproducible 100% Steps to reproduce 1. Open gedit 2. Click on "Open" 3. Start yping in the search field Actual result: gnome-shell/mutter dies taking the whole session with it. Expected results: No crash Additional data: (gdb) bt
+ Trace 236580
The Cogl error from cogl_wayland_texture_2d_new_from_buffer() is "Failed to create texture 2d due to size/format constraints"
And cogl fails because the given buffer has an invalid height (448x19896)
WAYLAND_DEBUG to the rescue.... What we see is that cogl_wayland_texture_2d_new_from_buffer() fails because of size/format contriants, the buffer size looks very suspicious, it grows like: Cogl-Message: shm buffer (448x251) Cogl-Message: shm buffer (448x611) Cogl-Message: shm buffer (448x22176) and then cogl_wayland_texture_2d_new_from_buffer() fails On the other hand, running gedit with WAYLAND_DEBUG shows that the size is indeed set from gtk+ [892129.655] -> wl_shm@5.create_pool(new id wl_shm_pool@45, fd 17, 39739392) [892129.693] -> wl_shm_pool@45.create_buffer(new id wl_buffer@50, 0, 448, 22176, 1792, 0) [892288.393] -> wl_surface@33.attach(wl_buffer@50, 0, 0) [892288.432] -> wl_surface@33.set_buffer_scale(1) [892288.436] -> wl_surface@33.damage(0, 0, 448, 22176) [892288.457] -> wl_surface@33.frame(new id wl_callback@49) [892288.464] -> wl_surface@33.commit() [...] So the root cause might be in gtk+, but it's somehow worrisome that a client bug can take the entire compositor down. Besides, even if 448x22176 might seem large, it's still way smaller than the limit of 65535 in _gdk_wayland_display_create_window_impl()
The error is raised when _cogl_texture_2d_gl_can_create() returns false, i.e. when the driver cannot support a texture of the given size.
Seems like this is a client side bug then. Then again, mutter should handle misbehaving clients, maybe send an OOM if the buffer is too large?
FWIW, I can't seem to reproduce this issue. I tried the steps described in the first comment, but it works fine.
(In reply to Jonas Ådahl from comment #5) > Seems like this is a client side bug then. Then again, mutter should handle > misbehaving clients, maybe send an OOM if the buffer is too large? Yeah, I'm working on such a patch to post an error to a client when we can't deal with the given buffer (In reply to Jonas Ådahl from comment #6) > FWIW, I can't seem to reproduce this issue. I tried the steps described in > the first comment, but it works fine. As it depends on the driver used, I guess your HW/driver can support larger textures than mine...
Created attachment 334205 [details] [review] [PATCH] wayland: Survive an unsupported buffer size If cogl could create a texture from the client's given buffer, mutter would raise a fatal error and quit. As a result, a broken client might kill gnome-shell/mutter and take the entire Wayland session with it. Instead of raising a fatal error in this case, log the cogl error message and send the client an OOM error, so mutter/gnome-shell can survive an unsupported buffer size.
Created attachment 334206 [details] [review] [PATCH] wayland: Survive an unsupported buffer size Fix the nonsensical commit message...
Note, the root cause on gtk+/gedit side is being investigated in bug 770430
Review of attachment 334206 [details] [review]: This looks good for now. I suppose it'd be better to make state applying handle errors at all, so that we don't continue applying state just as before, possibly breaking various assumptions. But lets leave that for another patch, and stop crashing for now.
Comment on attachment 334206 [details] [review] [PATCH] wayland: Survive an unsupported buffer size (In reply to Jonas Ådahl from comment #11) > Review of attachment 334206 [details] [review] [review]: > > This looks good for now. I suppose it'd be better to make state applying > handle errors at all, so that we don't continue applying state just as > before, possibly breaking various assumptions. But lets leave that for > another patch, and stop crashing for now. Agreed. Meanwhile, attachment 334206 [details] [review] pushed in branch master as commit 1f570d5 - wayland: Survive an unsupported buffer size
*** Bug 770140 has been marked as a duplicate of this bug. ***