Bug 278728 – [GTK] WL: Data too big for buffer (4092 + 12 > 4096).

• Status: REOPENED
• Component: WebKitGTK

[Michael Catanzaro]

Then Epiphany UI process is being occasionally killed, presumably by mutter. It happens without any core dump, so the process is probably receiving SIGKILL? I think it might happen when closing a browser tab.

Fortunately, there are some error messages in my system journal when this happens:

Aug 27 07:55:57 dreamyard gnome-shell[2344]: WL: Data too big for buffer (4092 + 12 > 4096).
Aug 27 07:55:58 dreamyard gnome-shell[2344]: WL: error in client communication (pid 29818)
Aug 27 07:55:58 dreamyard epiphany[29818]: vkGetPhysicalDeviceSurfaceFormatsKHR(): A surface is no longer available. (VK_ERROR_SURFACE_LOST_KHR) (-100000000>
Aug 27 07:55:58 dreamyard epiphany[29818]: vkGetPhysicalDeviceSurfaceFormatsKHR(): A surface is no longer available. (VK_ERROR_SURFACE_LOST_KHR) (-100000000>
Aug 27 07:55:58 dreamyard epiphany[29818]: vkGetPhysicalDeviceSurfacePresentModesKHR(): A surface is no longer available. (VK_ERROR_SURFACE_LOST_KHR) (-1000>
Aug 27 07:55:58 dreamyard epiphany[29818]: vkCreateSwapchainKHR(): A surface is no longer available. (VK_ERROR_SURFACE_LOST_KHR) (-1000000000)
Aug 27 07:55:58 dreamyard epiphany[29818]: Error 32 (Broken pipe) dispatching to Wayland display.

[Michael Catanzaro]

I caught this when running with WAYLAND_DEBUG=1. Unfortunately all the debug output is useless. I have 10,000 lines of terminal scrollback, and it's just a bunch of delete events until the end of the scrollback:

[1344758.617] {Display Queue} wl_display#1.delete_id(210180)
[1344758.619] {Display Queue} wl_display#1.delete_id(210189)
[1344758.621] {Display Queue} wl_display#1.delete_id(210198)
[1344758.622] {Display Queue} wl_display#1.delete_id(210207)
[1344758.624] {Display Queue} wl_display#1.delete_id(210216)
[1344758.626] {Display Queue} wl_display#1.delete_id(210225)
[1344758.628] {Display Queue} wl_display#1.delete_id(210234)
[1344758.630] {Display Queue} wl_display#1.delete_id(210243)
[1344758.632] {Display Queue} wl_display#1.delete_id(210252)
[1344758.633] {Display Queue} wl_display#1.delete_id(210261)
[1344758.635] {Display Queue} wl_display#1.delete_id(210270)
[1344758.637] {Display Queue} wl_display#1.delete_id(210279)
[1344758.639] {Display Queue} wl_display#1.delete_id(210288)
[1344758.640] {Display Queue} wl_display#1.delete_id(210297)
[1344758.642] {Display Queue} wl_display#1.delete_id(210306)
[1344758.644] {Display Queue} wl_display#1.delete_id(210315)
[1344758.646] {Display Queue} wl_display#1.delete_id(210324)
[1344758.648] {Display Queue} wl_display#1.delete_id(210333)
[1344758.649] {Display Queue} wl_display#1.delete_id(210342)
Gdk-Message: 11:53:25.218: Error reading events from display: Broken pipe

[Michael Catanzaro]

Nobody from WebKit or GTK side knows how to debug this. I will likely report a GTK bug to complain that there is nothing we can do to figure out what is going wrong. Pretty sure it's a GTK bug because WebKit doesn't talk directly to the compositor, but it's hard to move this to the GTK issue tracker at this point without knowing basically anything about what's wrong.

The error is coming from gdk_event_source_check() in gdk/wayland/gdkeventsource.c, but I doubt a backtrace at the point of the error would actually be useful. We might need some debug mode equivalent to GDK_SYNCHRONIZE=1, though I'm not sure if that's even possible.

[Michael Catanzaro]

Notably, this "crash" occurs when closing an Epiphany browser tab. I don't think it happens at any other time.

[Michael Catanzaro]

Moved to https://gitlab.gnome.org/GNOME/gtk/-/issues/6993

[Michael Catanzaro]

Reopening:

swick says: "this just means the client didn't read from the wayland socket for too long"

That's more likely to be WebKit's fault rather than GTK's? Guess: destroying WebKitWebView is too slow?

[Michael Catanzaro]

Closing again, we suspect a bug in libwayland

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #6)
> Closing again, we suspect a bug in libwayland

Never mind.

"could be the app not dispatching events anymore, could be libwayland not reading from the socket anymore"

I should probably stop live blogging the discussion here.

[Michael Catanzaro]

Summary of problem here: https://gitlab.gnome.org/GNOME/gtk/-/issues/6993#note_2221436

I think we are probably blocking too long when destroying the WebKitWebView. mutter 47 has a much larger buffer and might "fix" this problem, but that doesn't help if using other compositors.