GNU bug report logs - #35003
27.0.50; SIGTERM in dconf worker

Previous Next

To reply to this bug, email your comments to 35003 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Welsh Duggan <mwd <at> cert.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.0.50; SIGTERM in dconf worker
Date: Tue, 26 Mar 2019 10:39:29 -0400

I work on a system that runs for months that I reach though a system
that reboots regularly.  On the long-running system, I run emacs
--daemon, which I then connect to with emacsclient.  When the system
in between my box and the long-running box reboots, I just reconnect and
re-attach to my session.  But at some point that stopped working, as the
emacs daemon dies at some point during the involuntary detachment in the
dconf worker thread.  I finally managed to catch this in a gdb session
running in tmux running emacs with --fg-daemon.

Thread 3 "dconf worker" received signal SIGTERM, Terminated.
[Switching to Thread 0x7fffea131700 (LWP 42577)]
0x00007ffff454854b in raise () from /lib64/libpthread.so.0
(gdb) show args
Argument list to give program being debugged when it is started is "--fg-daemon"
.
(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:

(gdb) xbacktrace
(gdb) thread 1
[Switching to thread 1 (Thread 0x7ffff7fca880 (LWP 42490))]
#0  0x00007ffff38cdcd9 in pselect () from /lib64/libc.so.6
(gdb) xbacktrace

Thread 1 "emacs-27.0.50" received signal SIGTERM, Terminated.
backtrace_p (pdl=0xd7acc0) at ../../src/src/eval.c:182
182     { return specpdl ? pdl >= specpdl : false; }
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(backtrace_p) will be abandoned.
When the function is done executing, GDB will silently stop.

The information below was saved into a draft at the beginning of the
emacs session.

In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit)
 of 2019-03-21 built on pd2.mallab.cert.org
Repository revision: 1fc6afbdf1ce0f8b23780bd4d2630ed49f365013
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12001000
System Description: Red Hat Enterprise Linux Server 7.5 (Maipo)

Configured using:
 'configure --without-toolkit-scroll-bars --with-wide-int
 --prefix=/home/mwd/ --with-jpeg=no --with-gif=no --with-tiff=no
 --with-gnutls=no --without-gconf
 PKG_CONFIG_PATH=/opt/rh/devtoolset-8/root/usr/lib64/pkgconfig'

Configured features:
XAW3D XPM PNG SOUND GSETTINGS GLIB NOTIFY INOTIFY LIBSELINUX LIBXML2
FREETYPE XFT ZLIB LUCID X11 XDBE XIM THREADS PDUMPER GMP

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=none
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  display-time-mode: t
  shell-dirtrack-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t

Load-path shadows:
None found.

Features:
(shadow sort flyspell ispell mail-extr gnus-msg gnus-art mm-uu mml2015
mm-view mml-smime mailcap gnus-sum gnus-group gnus-undo gnus-start
gnus-cloud nnimap nnmail mail-source utf7 netrc nnoo gnus-spec gnus-int
gnus-range gnus-win emacsbug sendmail elec-pair woman man view time
smime dig server python tramp-sh tramp tramp-loaddefs trampver
tramp-integration files-x tramp-compat ucs-normalize shell pcomplete
parse-time advice prolog smie align comint ansi-color ring whitespace
ps-print ps-print-loaddefs ps-def lpr picture message rmc puny
format-spec rfc822 mml mml-sec epa derived epg mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader gnus
nnheader gnus-util rmail rmail-loaddefs rfc2047 rfc2045 ietf-drums
time-date mail-utils mm-util mail-prsvr wid-edit generic-x dired-x dired
dired-loaddefs cmake-mode thingatpt rx cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs edmacro
kmacro finder-inf mule-util info package easymenu epg-config
url-handlers url-parse auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json subr-x map url-vars seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric
uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads inotify dynamic-setting system-font-setting
font-render-setting x-toolkit x multi-tty make-network-process emacs)


-- 
Michael Welsh Duggan
(mwd <at> cert.org)

Message #8 received at 35003 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Welsh Duggan <mwd <at> cert.org>
Cc: 35003 <at> debbugs.gnu.org
Subject: Re: bug#35003: 27.0.50; SIGTERM in dconf worker
Date: Tue, 26 Mar 2019 18:03:56 +0200

> From: Michael Welsh Duggan <mwd <at> 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.

Message #11 received at 35003 <at> debbugs.gnu.org (full text, mbox):

From: Michael Welsh Duggan <mwd <at> cert.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 35003 <at> debbugs.gnu.org
Subject: Re: bug#35003: 27.0.50; SIGTERM in dconf worker
Date: Tue, 26 Mar 2019 12:42:34 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Michael Welsh Duggan <mwd <at> 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 <at> cert.org)

Message #14 received at 35003 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Welsh Duggan <mwd <at> cert.org>
Cc: 35003 <at> debbugs.gnu.org
Subject: Re: bug#35003: 27.0.50; SIGTERM in dconf worker
Date: Tue, 26 Mar 2019 19:02:38 +0200

> From: Michael Welsh Duggan <mwd <at> cert.org>
> Cc: <35003 <at> debbugs.gnu.org>
> Date: Tue, 26 Mar 2019 12:42:34 -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?

I'm not sure, but the name dconf_gdbus_worker_thread sounds like it's
part of D-Bus?  But I don't see DBUS in your features list as reported
by report-emacs-bug.  Or maybe it's the Gsettings thing?
libdconfsettings.so seems to hint on that.

I guess I don't really know.  Maybe someone else could help us out.

Message #17 received at 35003 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Michael Welsh Duggan <mwd <at> cert.org>
Cc: 35003 <at> debbugs.gnu.org
Subject: Re: bug#35003: 27.0.50; SIGTERM in dconf worker
Date: Thu, 28 Mar 2019 11:39:42 -0700

This looks like Emacs bug#22174, where the workaround was to run the
Emacs daemon with $DISPLAY unset. See:

https://bugs.gnu.org/22174

Also see the following mildly-related bug reports (not involving Emacs):

https://bugzilla.redhat.com/show_bug.cgi?id=1576422

https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1072518

Message #20 received at 35003 <at> debbugs.gnu.org (full text, mbox):

From: Michael Welsh Duggan <mwd <at> cert.org>
To: <35003 <at> debbugs.gnu.org>
Subject: Re: bug#35003: 27.0.50; SIGTERM in dconf worker
Date: Mon, 01 Apr 2019 10:37:18 -0400

[Message part 1 (text/plain, inline)]

As it happened again, I'll attach the backtrace from the emacs thread at
the time.  Then I'll restart with an empty DISPLAY and see what happens.

[Message part 2 (text/plain, inline)]

#0  set_buffer_internal_2 (b=b <at> entry=0x1e66880) at ../../src/src/buffer.c:2132
2132		  if (sym->u.s.redirect == SYMBOL_LOCALIZED /* Just to be sure.  */
#0  0x00000000004f86a3 in set_buffer_internal_2 (b=b <at> entry=0x1e66880)
    at ../../src/src/buffer.c:2132
#1  0x00000000004f8c36 in set_buffer_internal_1 (b=0x1e66880)
    at ../../src/src/buffer.c:2085
#2  0x00000000004f8c36 in set_buffer_internal (b=0x1e66880)
    at ../../src/src/buffer.h:1137
#3  0x00000000004f8c36 in Fset_buffer (buffer_or_name=XIL(0x1e66885))
    at ../../src/src/buffer.c:2182
#4  0x000000000058afa6 in exec_byte_code
    (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=nargs <at> entry=1, args=<optimized out>, 
    args <at> entry=0x10) at ../../src/src/bytecode.c:1137
#5  0x0000000000556230 in funcall_lambda
    (fun=XIL(0x7fffffffbe80), nargs=nargs <at> entry=1, arg_vector=0x10, 
    arg_vector <at> entry=0x7fffffffc048) at ../../src/src/lisp.h:1840
#6  0x000000000055381f in Ffuncall
    (nargs=nargs <at> entry=2, args=args <at> entry=0x7fffffffc040)
    at ../../src/src/eval.c:2861
#7  0x000000000055395a in call1
    (fn=fn <at> entry=XIL(0x1cbd185), arg1=<optimized out>)
    at ../../src/src/eval.c:2698
#8  0x000000000055c487 in mapcar1
    (leni=leni <at> entry=25, vals=vals <at> entry=0x7fffffffc0c0, fn=fn <at> entry=XIL(0x1cbd185), seq=seq <at> entry=XIL(0x20546a3)) at ../../src/src/lisp.h:1431
#9  0x000000000055f0b6 in Fmapcar
    (function=XIL(0x1cbd185), sequence=XIL(0x20546a3))
    at ../../src/src/fns.c:2709
#10 0x00000000005538a3 in Ffuncall (nargs=3, args=args <at> entry=0x7fffffffc268)
    at ../../src/src/lisp.h:2097
#11 0x00000000005896d0 in exec_byte_code
    (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=nargs <at> entry=0, args=<optimized out>, 
    args <at> entry=0xd) at ../../src/src/bytecode.c:633
#12 0x0000000000556230 in funcall_lambda
    (fun=XIL(0x7fffffffc280), nargs=nargs <at> entry=0, arg_vector=0xd, 
    arg_vector <at> entry=0x7fffffffc5e0) at ../../src/src/lisp.h:1840
#13 0x000000000055381f in Ffuncall
    (nargs=nargs <at> entry=1, args=args <at> entry=0x7fffffffc5d8)
    at ../../src/src/eval.c:2861
#14 0x0000000000553bbc in Fapply (nargs=2, args=0x7fffffffc5d8)
    at ../../src/src/eval.c:2420
#15 0x00000000005538a3 in Ffuncall (nargs=3, args=args <at> entry=0x7fffffffc5d0)
    at ../../src/src/lisp.h:2097
#16 0x00000000005896d0 in exec_byte_code
    (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=nargs <at> entry=0, args=<optimized out>, 
    args <at> entry=0xb) at ../../src/src/bytecode.c:633
#17 0x0000000000556230 in funcall_lambda
    (fun=XIL(0x7fffffffc5e8), nargs=nargs <at> entry=0, arg_vector=0xb, 
    arg_vector <at> entry=0x7fffffffc890) at ../../src/src/lisp.h:1840
#18 0x000000000055381f in Ffuncall
    (nargs=nargs <at> entry=1, args=args <at> entry=0x7fffffffc888)
    at ../../src/src/eval.c:2861
#19 0x0000000000553bbc in Fapply (nargs=2, args=0x7fffffffc888)
    at ../../src/src/eval.c:2420
#20 0x00000000005538a3 in Ffuncall (nargs=3, args=args <at> entry=0x7fffffffc880)
    at ../../src/src/lisp.h:2097
#21 0x00000000005896d0 in exec_byte_code
    (bytestr=<optimized out>, vector=<optimized out>, maxdepth=<optimized out>, args_template=<optimized out>, nargs=nargs <at> entry=1, args=<optimized out>, 
    args <at> entry=0x7) at ../../src/src/bytecode.c:633
#22 0x0000000000556230 in funcall_lambda
    (fun=XIL(0x7fffffffc8b8), nargs=nargs <at> entry=1, arg_vector=0x7, 
    arg_vector <at> entry=0x7fffffffcb18) at ../../src/src/lisp.h:1840
#23 0x000000000055381f in Ffuncall
    (nargs=nargs <at> entry=2, args=args <at> entry=0x7fffffffcb10)
    at ../../src/src/eval.c:2861
#24 0x000000000055395a in call1
    (fn=fn <at> entry=XIL(0xc300), arg1=arg1 <at> entry=XIL(0x2561ea5))
    at ../../src/src/eval.c:2698
#25 0x00000000004df9ac in timer_check_2 (idle_timers=XIL(0), timers=XIL(0x3584033)) at ../../src/src/lisp.h:1057
#26 0x00000000004df9ac in timer_check () at ../../src/src/keyboard.c:4367
#27 0x00000000004dfc55 in readable_events (flags=1) at ../../src/src/keyboard.c:3368
#28 0x00000000004e05e8 in get_input_pending (flags=flags <at> entry=1) at ../../src/src/keyboard.c:6771
#29 0x00000000004e2ce8 in detect_input_pending_run_timers (do_display=do_display <at> entry=true) at ../../src/src/keyboard.c:9915
#30 0x0000000000593ee3 in wait_reading_process_output (time_limit=time_limit <at> entry=30, nsecs=nsecs <at> entry=0, read_kbd=read_kbd <at> entry=-1, do_display=do_display <at> entry=true, wait_for_cell=wait_for_cell <at> entry=XIL(0), wait_proc=wait_proc <at> entry=0x0, just_wait_proc=0) at ../../src/src/process.c:5560
#31 0x000000000041a22e in sit_for (timeout=timeout <at> entry=make_number(30), reading=reading <at> entry=true, display_option=display_option <at> entry=1) at ../../src/src/lisp.h:1057
#32 0x00000000004e57f2 in read_char (commandflag=commandflag <at> entry=1, map=map <at> entry=XIL(0x35841b3), prev_event=XIL(0), used_mouse_menu=used_mouse_menu <at> entry=0x7fffffffd6bb, end_time=end_time <at> entry=0x0) at ../../src/src/lisp.h:1154
#33 0x00000000004e5e7e in read_key_sequence (keybuf=keybuf <at> entry=0x7fffffffd7b0, prompt=prompt <at> entry=XIL(0), dont_downcase_last=dont_downcase_last <at> entry=false, can_return_switch_frame=can_return_switch_frame <at> entry=true, fix_current_buffer=fix_current_buffer <at> entry=true, prevent_redisplay=prevent_redisplay <at> entry=false) at ../../src/src/keyboard.c:9110
#34 0x00000000004e762e in command_loop_1 () at ../../src/src/lisp.h:1057
#35 0x0000000000552a9e in internal_condition_case (bfun=bfun <at> entry=0x4e7460 <command_loop_1>, handlers=handlers <at> entry=XIL(0x5010), hfun=hfun <at> entry=0x4ded90 <cmd_error>) at ../../src/src/eval.c:1369
#36 0x00000000004d9c8c in command_loop_2 (ignore=ignore <at> entry=XIL(0)) at ../../src/src/lisp.h:1057
#37 0x0000000000552a0d in internal_catch (tag=tag <at> entry=XIL(0xc5d0), func=func <at> entry=0x4d9c70 <command_loop_2>, arg=arg <at> entry=XIL(0)) at ../../src/src/eval.c:1132
#38 0x00000000004d9c34 in command_loop () at ../../src/src/lisp.h:1057
#39 0x00000000004de996 in recursive_edit_1 () at ../../src/src/keyboard.c:714
#40 0x00000000004decb7 in Frecursive_edit () at ../../src/src/keyboard.c:785
#41 0x0000000000410732 in main (argc=2, argv=0x7fffffffdb38) at ../../src/src/emacs.c:1958

Thread 1 "emacs-27.0.50" received signal SIGTERM, Terminated.
backtrace_p (pdl=0xd7af40) at ../../src/src/eval.c:182
182	{ return specpdl ? pdl >= specpdl : false; }
The program being debugged was signaled while in a function called from GDB.
GDB has restored the context to what it was before the call.
To change this behavior use "set unwindonsignal off".
Evaluation of the expression containing the function
(backtrace_p) will be abandoned.

[Message part 3 (text/plain, inline)]

-- 
Michael Welsh Duggan
(mwd <at> cert.org)

Message #23 received at 35003 <at> debbugs.gnu.org (full text, mbox):

From: Michael Welsh Duggan <mwd <at> cert.org>
To: <35003 <at> debbugs.gnu.org>
Subject: Re: bug#35003: 27.0.50; SIGTERM in dconf worker
Date: Tue, 09 Apr 2019 09:14:24 -0400

Michael Welsh Duggan <mwd <at> cert.org> writes:

> As it happened again, I'll attach the backtrace from the emacs thread at
> the time.  Then I'll restart with an empty DISPLAY and see what happens.

I can state that the workaround of unsetting DISPLAY before starting the
daemon seems to have worked.  I now wonder if this is something that can
be fixed by unsetting DISPLAY in --daemon handling, or if it is being
used by an attached library before emacs has a chance to do that.

-- 
Michael Welsh Duggan
(mwd <at> cert.org)

Message #26 received at 35003 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 35003 <at> debbugs.gnu.org, Michael Welsh Duggan <mwd <at> cert.org>
Subject: Re: bug#35003: 27.0.50; SIGTERM in dconf worker
Date: Sat, 22 Jan 2022 16:31:58 +0100

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> This looks like Emacs bug#22174, where the workaround was to run the
> Emacs daemon with $DISPLAY unset. See:
>
> https://bugs.gnu.org/22174

I'm therefore merging these two bugs.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.