GNOME Bugzilla – Bug 768958
crashes when beeping the display
Last modified: 2018-04-15 00:14:53 UTC
I encounter this crash everytime I try to run this command: find . -type f | xargs sed 's/exec python/exec python2.7/' Inside Google's depot_tools repository (you can clone it with: git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git Here is the output logged in the journal: lug 19 17:33:32 wil93-arch systemd[2287]: gnome-terminal-server.service: Main process exited, code=dumped, status=6/ABRT lug 19 17:33:32 wil93-arch systemd[2287]: gnome-terminal-server.service: Unit entered failed state. lug 19 17:33:32 wil93-arch systemd[2287]: gnome-terminal-server.service: Failed with result 'core-dump'. lug 19 17:33:33 wil93-arch systemd-coredump[14487]: Process 14435 (gnome-terminal-) of user 1000 dumped core. Stack trace of thread 14435: #0 0x00007f4cfeb83225 __GI_raise (libc.so.6) #1 0x00007f4cfeb8466a __GI_abort (libc.so.6) #2 0x00007f4cfb0ccfe7 wl_abort (libwayland-client.so.0) #3 0x00007f4cfb0c9165 wl_proxy_marshal_array_constructor_versioned (libwayland-client.so.0) #4 0x00007f4cfb0c92b4 wl_proxy_marshal (libwayland-client.so.0) #5 0x00007f4d00e667c9 vte_sequence_handler_bell (libvte-2.91.so.0) #6 0x00007f4d00e56ab7 _ZN18VteTerminalPrivate16process_incomingEv (libvte-2.91.so.0) #7 0x00007f4d00e57bf1 _ZN18VteTerminalPrivate21time_process_incomingEv (libvte-2.91.so.0) #8 0x00007f4d00e57cd8 _ZN18VteTerminalPrivate7processEb (libvte-2.91.so.0) #9 0x00007f4d00e58009 update_repeat_timeout (libvte-2.91.so.0) #10 0x00007f4cff35d713 g_timeout_dispatch (libglib-2.0.so.0) #11 0x00007f4cff35cc9a g_main_dispatch (libglib-2.0.so.0) #12 0x00007f4cff35d050 g_main_context_iterate (libglib-2.0.so.0) #13 0x00007f4cff35d0fc g_main_context_iteration (libglib-2.0.so.0) #14 0x00007f4cff921d9d g_application_run (libgio-2.0.so.0) #15 0x00000000004125c9 main (gnome-terminal-server) #16 0x00007f4cfeb70741 __libc_start_main (libc.so.6) #17 0x00000000004126f9 _start (gnome-terminal-server) Stack trace of thread 14437: #0 0x00007f4cfec2e9fd poll (libc.so.6) #1 0x00007f4cff35cfe6 g_main_context_poll (libglib-2.0.so.0) #2 0x00007f4cff35d0fc g_main_context_iteration (libglib-2.0.so.0) #3 0x00007f4cff35d141 glib_worker_main (libglib-2.0.so.0) #4 0x00007f4cff3832a5 g_thread_proxy (libglib-2.0.so.0) #5 0x00007f4cfeef8484 start_thread (libpthread.so.0) #6 0x00007f4cfec37a5d __clone (libc.so.6) Stack trace of thread 14438: #0 0x00007f4cfec2e9fd poll (libc.so.6) #1 0x00007f4cff35cfe6 g_main_context_poll (libglib-2.0.so.0) #2 0x00007f4cff35d372 g_main_loop_run (libglib-2.0.so.0) #3 0x00007f4cff958806 gdbus_shared_thread_func (libgio-2.0.so.0) #4 0x00007f4cff3832a5 g_thread_proxy (libglib-2.0.so.0) #5 0x00007f4cfeef8484 start_thread (libpthread.so.0) #6 0x00007f4cfec37a5d __clone (libc.so.6) Stack trace of thread 14440: #0 0x00007f4cfec335d9 syscall (libc.so.6) #1 0x00007f4cff3a131a g_cond_wait_until (libglib-2.0.so.0) #2 0x00007f4cff331a19 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0) #3 0x00007f4cff33203c g_async_queue_timeout_pop (libglib-2.0.so.0) #4 0x00007f4cff383d6d g_thread_pool_wait_for_new_pool (libglib-2.0.so.0) #5 0x00007f4cff3832a5 g_thread_proxy (libglib-2.0.so.0) #6 0x00007f4cfeef8484 start_thread (libpthread.so.0) #7 0x00007f4cfec37a5d __clone (libc.so.6) Stack trace of thread 14436: #0 0x00007f4cfec2e9fd poll (libc.so.6) #1 0x00007f4cff35cfe6 g_main_context_poll (libglib-2.0.so.0) #2 0x00007f4cff35d0fc g_main_context_iteration (libglib-2.0.so.0) #3 0x00007f4cf42e443d n/a (libdconfsettings.so) #4 0x00007f4cff3832a5 g_thread_proxy (libglib-2.0.so.0) #5 0x00007f4cfeef8484 start_thread (libpthread.so.0) #6 0x00007f4cfec37a5d __clone (libc.so.6)
vte_sequence_handler_bell() is handling a BEL; does just $ printf '\007' reproduce the problem? Or perhaps when doing this in a loop? The trace is a bit odd, it's certainly missing several elements between #4 and #5 since vte_sequence_handler_bell() doesn't directly call any wayland APIs. I think this is below gdk_display_beep() in which case it will be a gtk+ or wayland problem.
The printf you suggested does not seem to reproduce the problem. I also tried: for ((i=0; i<1000; i++)); do printf '\007'; done to no avail... I think it can be triggered with the command I initially posted (using a folder with a lot of files, e.g. the depot_tools repo).
Since it's crashing below gdk_display_beep() afaict, let's reassign this to gtk+:wayland.
gdk_display_beep works just fine here. Whats the Wayland compositor in the original report ?
I tried to reproduce this today and gnome-terminal still crashes. Guake, surprisingly, does not crash.
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new