Bug 1743144 Comment 36 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

I'm also seeing this on sway several times an hour.

```
Gdk-Message: 08:29:24.126: Lost connection to Wayland compositor.

Thread 1 "firefox-bin" hit Breakpoint 3, __GI__exit (status=status@entry=1) at ../sysdeps/unix/sysv/linux/_exit.c:27
27	{
(gdb) bt
#0  __GI__exit (status=status@entry=1) at ../sysdeps/unix/sysv/linux/_exit.c:27
#1  0x00007ffff636b7c3 in _gdk_wayland_display_queue_events (display=<optimized out>) at ../gtk/gdk/wayland/gdkeventsource.c:211
#2  0x00007ffff6338029 in gdk_display_get_event (display=0x7ffff7844200) at ../gtk/gdk/gdkdisplay.c:442
#3  0x00007ffff6372728 in gdk_event_source_dispatch (base=<optimized out>, callback=<optimized out>, data=<optimized out>) at ../gtk/gdk/wayland/gdkeventsource.c:120
#4  0x00007ffff621d87b in g_main_dispatch (context=0x7fffe850adf0) at ../glib/glib/gmain.c:3454
#5  g_main_context_dispatch (context=0x7fffe850adf0) at ../glib/glib/gmain.c:4172
#6  0x00007ffff6274c89 in g_main_context_iterate.constprop.0 (context=0x7fffe850adf0, block=0, dispatch=1, self=<optimized out>) at ../glib/glib/gmain.c:4248
#7  0x00007ffff621c132 in g_main_context_iteration (context=0x7fffe850adf0, may_block=0) at ../glib/glib/gmain.c:4313
#8  0x00007fffed6f989f in nsThread::ProcessNextEvent(bool, bool*) () at /home/the8472/opt/firefox/libxul.so
#9  0x00007fffed744054 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) () at /home/the8472/opt/firefox/libxul.so
#10 0x00007fffee2a2e5f in MessageLoop::Run() () at /home/the8472/opt/firefox/libxul.so
#11 0x00007fffee9b8469 in nsBaseAppShell::Run() () at /home/the8472/opt/firefox/libxul.so
#12 0x00007fffec451d45 in nsAppStartup::Run() () at /home/the8472/opt/firefox/libxul.so
#13 0x00007fffec4dac9b in XREMain::XRE_mainRun() () at /home/the8472/opt/firefox/libxul.so
#14 0x00007fffec4db683 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) () at /home/the8472/opt/firefox/libxul.so
#15 0x00007fffec4dba66 in XRE_main(int, char**, mozilla::BootstrapConfig const&) () at /home/the8472/opt/firefox/libxul.so
#16 0x00005555555e7cfc in main ()
```

(In reply to Robert Mader [:rmader] from comment #14)
> (In reply to Emilio Cobos Álvarez (:emilio) from comment #10)
> > ...
> > Which should just stop responding for a bit, instead we crash.
> 
> For the record, this might trigger an yet unsolved problem on Wayland: if the main thread is blocked long enough and does not read from the wayland socket, the buffer will fill up. Once that happens, the connection gets terminated. This happens especially fast with e.g. 1000Hz mice, see e.g. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915#note_1197910

Is it possible to increase the buffer size?
I'm also seeing this on sway several times an hour (using nightly).

```
Gdk-Message: 08:29:24.126: Lost connection to Wayland compositor.

Thread 1 "firefox-bin" hit Breakpoint 3, __GI__exit (status=status@entry=1) at ../sysdeps/unix/sysv/linux/_exit.c:27
27	{
(gdb) bt
#0  __GI__exit (status=status@entry=1) at ../sysdeps/unix/sysv/linux/_exit.c:27
#1  0x00007ffff636b7c3 in _gdk_wayland_display_queue_events (display=<optimized out>) at ../gtk/gdk/wayland/gdkeventsource.c:211
#2  0x00007ffff6338029 in gdk_display_get_event (display=0x7ffff7844200) at ../gtk/gdk/gdkdisplay.c:442
#3  0x00007ffff6372728 in gdk_event_source_dispatch (base=<optimized out>, callback=<optimized out>, data=<optimized out>) at ../gtk/gdk/wayland/gdkeventsource.c:120
#4  0x00007ffff621d87b in g_main_dispatch (context=0x7fffe850adf0) at ../glib/glib/gmain.c:3454
#5  g_main_context_dispatch (context=0x7fffe850adf0) at ../glib/glib/gmain.c:4172
#6  0x00007ffff6274c89 in g_main_context_iterate.constprop.0 (context=0x7fffe850adf0, block=0, dispatch=1, self=<optimized out>) at ../glib/glib/gmain.c:4248
#7  0x00007ffff621c132 in g_main_context_iteration (context=0x7fffe850adf0, may_block=0) at ../glib/glib/gmain.c:4313
#8  0x00007fffed6f989f in nsThread::ProcessNextEvent(bool, bool*) () at /home/the8472/opt/firefox/libxul.so
#9  0x00007fffed744054 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) () at /home/the8472/opt/firefox/libxul.so
#10 0x00007fffee2a2e5f in MessageLoop::Run() () at /home/the8472/opt/firefox/libxul.so
#11 0x00007fffee9b8469 in nsBaseAppShell::Run() () at /home/the8472/opt/firefox/libxul.so
#12 0x00007fffec451d45 in nsAppStartup::Run() () at /home/the8472/opt/firefox/libxul.so
#13 0x00007fffec4dac9b in XREMain::XRE_mainRun() () at /home/the8472/opt/firefox/libxul.so
#14 0x00007fffec4db683 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) () at /home/the8472/opt/firefox/libxul.so
#15 0x00007fffec4dba66 in XRE_main(int, char**, mozilla::BootstrapConfig const&) () at /home/the8472/opt/firefox/libxul.so
#16 0x00005555555e7cfc in main ()
```

Edit: note that this kills firefox in a way that it doesn't even submit crash reports.

(In reply to Robert Mader [:rmader] from comment #14)
> (In reply to Emilio Cobos Álvarez (:emilio) from comment #10)
> > ...
> > Which should just stop responding for a bit, instead we crash.
> 
> For the record, this might trigger an yet unsolved problem on Wayland: if the main thread is blocked long enough and does not read from the wayland socket, the buffer will fill up. Once that happens, the connection gets terminated. This happens especially fast with e.g. 1000Hz mice, see e.g. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915#note_1197910

Is it possible to increase the buffer size?
I'm also seeing this on [sway](https://swaywm.org/) several times an hour (using nightly).

```
Gdk-Message: 08:29:24.126: Lost connection to Wayland compositor.

Thread 1 "firefox-bin" hit Breakpoint 3, __GI__exit (status=status@entry=1) at ../sysdeps/unix/sysv/linux/_exit.c:27
27	{
(gdb) bt
#0  __GI__exit (status=status@entry=1) at ../sysdeps/unix/sysv/linux/_exit.c:27
#1  0x00007ffff636b7c3 in _gdk_wayland_display_queue_events (display=<optimized out>) at ../gtk/gdk/wayland/gdkeventsource.c:211
#2  0x00007ffff6338029 in gdk_display_get_event (display=0x7ffff7844200) at ../gtk/gdk/gdkdisplay.c:442
#3  0x00007ffff6372728 in gdk_event_source_dispatch (base=<optimized out>, callback=<optimized out>, data=<optimized out>) at ../gtk/gdk/wayland/gdkeventsource.c:120
#4  0x00007ffff621d87b in g_main_dispatch (context=0x7fffe850adf0) at ../glib/glib/gmain.c:3454
#5  g_main_context_dispatch (context=0x7fffe850adf0) at ../glib/glib/gmain.c:4172
#6  0x00007ffff6274c89 in g_main_context_iterate.constprop.0 (context=0x7fffe850adf0, block=0, dispatch=1, self=<optimized out>) at ../glib/glib/gmain.c:4248
#7  0x00007ffff621c132 in g_main_context_iteration (context=0x7fffe850adf0, may_block=0) at ../glib/glib/gmain.c:4313
#8  0x00007fffed6f989f in nsThread::ProcessNextEvent(bool, bool*) () at /home/the8472/opt/firefox/libxul.so
#9  0x00007fffed744054 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) () at /home/the8472/opt/firefox/libxul.so
#10 0x00007fffee2a2e5f in MessageLoop::Run() () at /home/the8472/opt/firefox/libxul.so
#11 0x00007fffee9b8469 in nsBaseAppShell::Run() () at /home/the8472/opt/firefox/libxul.so
#12 0x00007fffec451d45 in nsAppStartup::Run() () at /home/the8472/opt/firefox/libxul.so
#13 0x00007fffec4dac9b in XREMain::XRE_mainRun() () at /home/the8472/opt/firefox/libxul.so
#14 0x00007fffec4db683 in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) () at /home/the8472/opt/firefox/libxul.so
#15 0x00007fffec4dba66 in XRE_main(int, char**, mozilla::BootstrapConfig const&) () at /home/the8472/opt/firefox/libxul.so
#16 0x00005555555e7cfc in main ()
```

Edit: note that this kills firefox in a way that it doesn't even submit crash reports.

(In reply to Robert Mader [:rmader] from comment #14)
> (In reply to Emilio Cobos Álvarez (:emilio) from comment #10)
> > ...
> > Which should just stop responding for a bit, instead we crash.
> 
> For the record, this might trigger an yet unsolved problem on Wayland: if the main thread is blocked long enough and does not read from the wayland socket, the buffer will fill up. Once that happens, the connection gets terminated. This happens especially fast with e.g. 1000Hz mice, see e.g. https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1915#note_1197910

Is it possible to increase the buffer size?

Back to Bug 1743144 Comment 36