bug#35003: 27.0.50; SIGTERM in dconf worker

[Michael Welsh Duggan]

Eli Zaretskii <eliz@gnu.org> writes:

>> 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?

No.  But I don't know why it is being used at all.  What configure
option do I have to use to have it not create this dconf worker under
the hood?

>> (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.

I'll try again once I trigger the problem again.  I lost the last gdb
session.  

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

I'd be happy for this not to be an Emacs problem.  Until I can figure
out how to build Emacs without it, it is an Emacs problem, though.

-- 
Michael Welsh Duggan
(mwd@cert.org)