Subject: bug#35003: 27.0.50; SIGTERM in dconf worker

From: Eli Zaretskii <[email-masked]>
Date: Tue, 26 Mar 2019 18:03:56 +0200

> From: Michael Welsh Duggan <[email-masked]>
> Date: Tue, 26 Mar 2019 10:39:29 -0400
> 
> Thread 3 "dconf worker" received signal SIGTERM, Terminated.

That thread is not ours, is it?

> (gdb) info thread
>   Id   Target Id                                         Frame 
>   1    Thread 0x7ffff7fca880 (LWP 42490) "emacs-27.0.50" 0x00007ffff38cdcd9 in p
> select () from /lib64/libc.so.6
>   2    Thread 0x7fffead4a700 (LWP 42492) "gmain"         0x00007ffff38cbe9d in p
> oll () from /lib64/libc.so.6
> * 3    Thread 0x7fffea131700 (LWP 42577) "dconf worker"  0x00007ffff454854b in r
> aise () from /lib64/libpthread.so.0
>   4    Thread 0x7fffe9930700 (LWP 42583) "gdbus"         0x00007ffff38cbe9d in p
> oll () from /lib64/libc.so.6
> (gdb) bt
> #0  0x00007ffff454854b in raise () at /lib64/libpthread.so.0
> #1  0x00007ffff2da2dcc in ffi_call_unix64 () at /lib64/libffi.so.6
> #2  0x00007ffff2da26f5 in ffi_call () at /lib64/libffi.so.6
> #3  0x00007ffff5183675 in g_cclosure_marshal_generic_va ()
>     at /lib64/libgobject-2.0.so.0
> #4  0x00007ffff5182c07 in _g_closure_invoke_va () at /lib64/libgobject-2.0.so.0
> #5  0x00007ffff519c757 in g_signal_emit_valist () at /lib64/libgobject-2.0.so.0
> #6  0x00007ffff519d3df in g_signal_emit () at /lib64/libgobject-2.0.so.0
> #7  0x00007ffff547d075 in emit_closed_in_idle () at /lib64/libgio-2.0.so.0
> #8  0x00007ffff4ea64e7 in g_idle_dispatch () at /lib64/libglib-2.0.so.0
> #9  0x00007ffff4ea98f9 in g_main_context_dispatch () at /lib64/libglib-2.0.so.0
> #10 0x00007ffff4ea9c58 in g_main_context_iterate.isra ()
>     at /lib64/libglib-2.0.so.0
> #11 0x00007ffff4ea9d0c in g_main_context_iteration ()
>     at /lib64/libglib-2.0.so.0
> #12 0x00007fffea13948d in dconf_gdbus_worker_thread ()
>     at /usr/lib64/gio/modules/libdconfsettings.so
> #13 0x00007ffff4ed0900 in g_thread_proxy () at /lib64/libglib-2.0.so.0
> #14 0x00007ffff4540dd5 in start_thread () at /lib64/libpthread.so.0
> #15 0x00007ffff38d6b3d in clone () at /lib64/libc.so.6
> 
> 
> Unfortunately, xbacktrace doesn't seem to be working very well in this
> state:

We can still use the C-level backtrace for the main thread, so just
"bt" after switching to thread 1 would be useful.

However, I wonder whether this is an Emacs problem if the signal
always happens in the dconf thread.