From: Michael Welsh Duggan <mwd@cert.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 35003@debbugs.gnu.org
Subject: bug#35003: 27.0.50; SIGTERM in dconf worker
Date: Tue, 26 Mar 2019 12:42:34 -0400 [thread overview]
Message-ID: <tnto95xlh8l.fsf@lx-chumsalmon.ad.sei.cmu.edu> (raw)
In-Reply-To: <834l7pmxlf.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 26 Mar 2019 18:03:56 +0200")
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)
next prev parent reply other threads:[~2019-03-26 16:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-26 14:39 bug#35003: 27.0.50; SIGTERM in dconf worker Michael Welsh Duggan
2019-03-26 16:03 ` Eli Zaretskii
2019-03-26 16:42 ` Michael Welsh Duggan [this message]
2019-03-26 17:02 ` Eli Zaretskii
2019-04-01 14:37 ` Michael Welsh Duggan
2019-04-09 13:14 ` Michael Welsh Duggan
2019-03-28 18:39 ` Paul Eggert
2022-01-22 15:31 ` Lars Ingebrigtsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=tnto95xlh8l.fsf@lx-chumsalmon.ad.sei.cmu.edu \
--to=mwd@cert.org \
--cc=35003@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.