[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#35003: 27.0.50; SIGTERM in dconf worker
From: |
Eli Zaretskii |
Subject: |
bug#35003: 27.0.50; SIGTERM in dconf worker |
Date: |
Tue, 26 Mar 2019 18:03:56 +0200 |
> From: Michael Welsh Duggan <mwd@cert.org>
> 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.