GNU bug report logs - #58960
29.0.50; Assert fails when browsing an URL

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 58960 in the body.
You can then email your comments to 58960 AT debbugs.gnu.org in the normal way.

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

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

From: Tino Calancha <tino.calancha <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Assert fails when browsing an URL
Date: Wed, 2 Nov 2022 05:48:30 +0100 (CET)

emacs -Q
M-x browse-url RET
https://www.example.com RET

[The URL is opened by my default browser and Emacs crashes with the
following backtrace]

process.c:7386: Emacs fatal error: assertion failed: 0 <= fd
Fatal error 6: Aborted
Backtrace:
emacs[0x610be3]
emacs[0x5d806c]
emacs[0x68a1a0]
emacs[0x73b497]
emacs[0x73b900]
emacs[0x6103ae]
emacs[0x73b92b]
/lib64/libpthread.so.0(+0x12ce0)[0x7f937e22ace0]
emacs[0x669b85]
emacs[0x669bf0]
emacs[0x675dd7]
emacs[0x673dfc]
emacs[0x6736f3]
emacs[0x661f1f]
emacs[0x63996b]
emacs[0x63ac19]
emacs[0x6c5492]
emacs[0x7236f7]
emacs[0x6c578c]
emacs[0x6c5be4]
emacs[0x6c4f15]
emacs[0x6c520c]
emacs[0x6c406f]
emacs[0x6c5629]
emacs[0x7236f7]
emacs[0x6c578c]
emacs[0x6c5be4]
emacs[0x6c4f15]
emacs[0x6c520c]
emacs[0x5dd79a]
emacs[0x5ea9e8]
emacs[0x5eab38]
emacs[0x5e7b76]
emacs[0x5f1d97]
emacs[0x5fb14e]
emacs[0x5e486a]
emacs[0x5f9229]
emacs[0x5e090f]
emacs[0x6c0a85]
emacs[0x5e0110]
emacs[0x6bfd21]
emacs[0x5e00a8]
emacs[0x5df4a5]
emacs[0x5df6ad]
emacs[0x5db103]
/lib64/libc.so.6(__libc_start_main+0xf3)[0x7f937d057cf3]
emacs[0x4180ce]




In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.15.12, Xaw scroll bars) of 2022-11-02 built on
 tcalanch.remote.csb
Repository revision: 8a5678906fa1b899c4d111e5ee4334b278f50d48
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Red Hat Enterprise Linux 8.6 (Ootpa)

Configured using:
 'configure --enable-checking=yes,glyphs --enable-check-lisp-object-type
 --with-x-toolkit=lucid 'CFLAGS=-O0 -g3' --with-gif=ifavailable'

Configured features:
ACL CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG
LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG SECCOMP SOUND
THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM LUCID ZLIB

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

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-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
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc iso-transl tooltip cconv eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode 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 lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine 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 emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
theme-loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify
dynamic-setting system-font-setting font-render-setting cairo x-toolkit
xinput2 x multi-tty make-network-process emacs)

Memory information:
((conses 16 36693 5402)
 (symbols 48 5093 0)
 (strings 32 13962 1228)
 (string-bytes 1 383102)
 (vectors 16 9295)
 (vector-slots 8 147845 11034)
 (floats 8 34 25)
 (intervals 56 239 0)
 (buffers 984 10))

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: tino.calancha <at> gmail.com
Cc: 58960 <at> debbugs.gnu.org
Subject: Re: bug#58960: 29.0.50; Assert fails when browsing an URL
Date: Wed, 2 Nov 2022 06:14:07 +0100

FWIW, this is not reproducible on macOS.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Tino Calancha <tino.calancha <at> gmail.com>
Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
 58960 <at> debbugs.gnu.org
Subject: Re: bug#58960: 29.0.50; Assert fails when browsing an URL,
 bug#58960: 29.0.50; Assert fails when browsing an URL
Date: Wed, 02 Nov 2022 11:20:31 +0100

>>>>> On Wed, 2 Nov 2022 05:48:30 +0100 (CET), Tino Calancha <tino.calancha <at> gmail.com> said:

    Tino> emacs -Q
    Tino> M-x browse-url RET
    Tino> https://www.example.com RET

    Tino> [The URL is opened by my default browser and Emacs crashes with the
    Tino> following backtrace]

    Tino> process.c:7386: Emacs fatal error: assertion failed: 0 <= fd

This goes away if you do something like 'M-x shell' first, right?

Looks like `call-process' needs to ensure the child signal fdʼs are
set up before calling `emacs_spawn'. Iʼm suprised nobody has run into
this before. Does the (dirty) patch below fix things for you?

Robert
-- 

diff --git i/src/process.c w/src/process.c
index 358899cded..4690addcf1 100644
--- i/src/process.c
+++ w/src/process.c
@@ -292,7 +292,7 @@ network_lookup_address_info_1 (Lisp_Object host, const char *service,
    descriptor to notify `wait_reading_process_output' of process
    status changes.  */
 static int child_signal_write_fd = -1;
-static void child_signal_init (void);
+void child_signal_init (void);
 #ifndef WINDOWSNT
 static void child_signal_read (int, void *);
 #endif
@@ -7323,7 +7323,7 @@ DEFUN ("process-send-eof", Fprocess_send_eof, Sprocess_send_eof, 0, 1, 0,
 
 /* Set up `child_signal_read_fd' and `child_signal_write_fd'.  */
 
-static void
+void
 child_signal_init (void)
 {
   /* Either both are initialized, or both are uninitialized.  */
diff --git i/src/callproc.c w/src/callproc.c
index 4d4b86629c..10ec643861 100644
--- i/src/callproc.c
+++ w/src/callproc.c
@@ -328,7 +328,7 @@ DEFUN ("call-process", Fcall_process, Scall_process, 1, MANY, 0,
    this case NARGS must be at least 2 and ARGS[1] is the file's name.
 
    At entry, the specpdl stack top entry must be close_file_unwind (FILEFD).  */
-
+extern void child_signal_init (void);
 static Lisp_Object
 call_process (ptrdiff_t nargs, Lisp_Object *args, int filefd,
 	      specpdl_ref tempfile_index)
@@ -650,7 +650,7 @@ call_process (ptrdiff_t nargs, Lisp_Object *args, int filefd,
 
   block_input ();
   block_child_signal (&oldset);
-
+  child_signal_init ();
   child_errno
     = emacs_spawn (&pid, filefd, fd_output, fd_error, new_argv, env,
                    SSDATA (current_dir), NULL, false, false, &oldset);

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>, Paul Eggert <eggert <at> cs.ucla.edu>
Cc: gerd.moellmann <at> gmail.com, 58960 <at> debbugs.gnu.org, tino.calancha <at> gmail.com
Subject: Re: bug#58960: 29.0.50;
 Assert fails when browsing an URL, bug#58960: 29.0.50;
 Assert fails when browsing an URL
Date: Wed, 02 Nov 2022 15:10:07 +0200

> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
>  58960 <at> debbugs.gnu.org
> From: Robert Pluim <rpluim <at> gmail.com>
> Date: Wed, 02 Nov 2022 11:20:31 +0100
> 
> Looks like `call-process' needs to ensure the child signal fdʼs are
> set up before calling `emacs_spawn'.

Why do we need this?  IOW, do you understand how did SIGCHLD cause
this?

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: gerd.moellmann <at> gmail.com, 58960 <at> debbugs.gnu.org,
 Paul Eggert <eggert <at> cs.ucla.edu>, tino.calancha <at> gmail.com
Subject: Re: bug#58960: 29.0.50; Assert fails when browsing an URL,
 bug#58960: 29.0.50; Assert fails when browsing an URL
Date: Wed, 02 Nov 2022 14:58:23 +0100

>>>>> On Wed, 02 Nov 2022 15:10:07 +0200, Eli Zaretskii <eliz <at> gnu.org> said:

    >> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
    >> 58960 <at> debbugs.gnu.org
    >> From: Robert Pluim <rpluim <at> gmail.com>
    >> Date: Wed, 02 Nov 2022 11:20:31 +0100
    >> 
    >> Looks like `call-process' needs to ensure the child signal fdʼs are
    >> set up before calling `emacs_spawn'.

    Eli> Why do we need this?  IOW, do you understand how did SIGCHLD cause
    Eli> this?

`browse-url' does `call-process' for `xdg-open' by default. `xdg-open'
exits almost immediately, we get SIGCHLD:

(gdb) bt
#0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:421
#1  0x00005555555b489e in die
    (msg=msg <at> entry=0x5555558d938f "0 <= fd", file=file <at> entry=0x5555558d9354 "process.c", line=line <at> entry=7386) at alloc.c:7692
#2  0x00005555555bfec9 in child_signal_notify () at process.c:7386
#3  handle_child_signal (sig=<optimized out>) at process.c:7493
#4  0x000055555574e992 in deliver_process_signal
    (sig=17, handler=0x555555831b40 <handle_child_signal>) at sysdep.c:1741
#5  0x00007ffff5752140 in <signal handler called> ()

`child_signal_notify' does this:

  int fd = child_signal_write_fd;
  eassert (0 <= fd);

and if `child_signal_init' hasnʼt been called, then this is still
true:

/* The write end thereof.  The SIGCHLD handler writes to this file
   descriptor to notify `wait_reading_process_output' of process
   status changes.  */
static int child_signal_write_fd = -1;

so the assert fails.

Why canʼt we just call `child_signal_init' from `init_process_emacs'
instead of `create_process'?

Robert
-- 

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>, eggert <at> cs.ucla.edu
Cc: gerd.moellmann <at> gmail.com, 58960 <at> debbugs.gnu.org, tino.calancha <at> gmail.com
Subject: Re: bug#58960: 29.0.50; Assert fails when browsing an URL,
 bug#58960: 29.0.50; Assert fails when browsing an URL
Date: Wed, 02 Nov 2022 17:09:45 +0200

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>,  tino.calancha <at> gmail.com,
>   gerd.moellmann <at> gmail.com,  58960 <at> debbugs.gnu.org
> Date: Wed, 02 Nov 2022 14:58:23 +0100
> 
> >>>>> On Wed, 02 Nov 2022 15:10:07 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
> 
>     >> Cc: Gerd Möllmann <gerd.moellmann <at> gmail.com>,
>     >> 58960 <at> debbugs.gnu.org
>     >> From: Robert Pluim <rpluim <at> gmail.com>
>     >> Date: Wed, 02 Nov 2022 11:20:31 +0100
>     >> 
>     >> Looks like `call-process' needs to ensure the child signal fdʼs are
>     >> set up before calling `emacs_spawn'.
> 
>     Eli> Why do we need this?  IOW, do you understand how did SIGCHLD cause
>     Eli> this?
> 
> `browse-url' does `call-process' for `xdg-open' by default. `xdg-open'
> exits almost immediately, we get SIGCHLD:

Ugh, xdg-open again...

> (gdb) bt
> #0  terminate_due_to_signal (sig=6, backtrace_limit=2147483647) at emacs.c:421
> #1  0x00005555555b489e in die
>     (msg=msg <at> entry=0x5555558d938f "0 <= fd", file=file <at> entry=0x5555558d9354 "process.c", line=line <at> entry=7386) at alloc.c:7692
> #2  0x00005555555bfec9 in child_signal_notify () at process.c:7386
> #3  handle_child_signal (sig=<optimized out>) at process.c:7493
> #4  0x000055555574e992 in deliver_process_signal
>     (sig=17, handler=0x555555831b40 <handle_child_signal>) at sysdep.c:1741
> #5  0x00007ffff5752140 in <signal handler called> ()
> 
> `child_signal_notify' does this:
> 
>   int fd = child_signal_write_fd;
>   eassert (0 <= fd);
> 
> and if `child_signal_init' hasnʼt been called, then this is still
> true:
> 
> /* The write end thereof.  The SIGCHLD handler writes to this file
>    descriptor to notify `wait_reading_process_output' of process
>    status changes.  */
> static int child_signal_write_fd = -1;
> 
> so the assert fails.
> 
> Why canʼt we just call `child_signal_init' from `init_process_emacs'
> instead of `create_process'?

Maybe we could.  Assuming the signal stuff is already set so early, I
don't know exactly how posix_spawn works.

Paul, WDYT about this?

Message #25 received at 58960-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>, Robert Pluim <rpluim <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, 58960-done <at> debbugs.gnu.org,
 tino.calancha <at> gmail.com
Subject: Re: bug#58960: 29.0.50; Assert fails when browsing an URL, bug#58960:
 29.0.50; Assert fails when browsing an URL
Date: Wed, 2 Nov 2022 13:29:39 -0700

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

On 11/2/22 08:09, Eli Zaretskii wrote:
>> Why canʼt we just call `child_signal_init' from `init_process_emacs'
>> instead of `create_process'?
> Maybe we could.  Assuming the signal stuff is already set so early, I
> don't know exactly how posix_spawn works.

child_signal_init is reasonably heavyweight in that it keeps a couple of 
file descriptors open, so the idea is to be lazy and not call it unless 
Emacs plans to have children.

I installed the attached, which is like Robert's patch except it keeps 
the critical section smaller and checks the declaration of the 
now-extern function. Please give it a try. I'll boldly close the bug 
report; we can reopen it if I'm wrong.

[0001-Initialize-child-signal-handling-before-posix_spawn-.patch (text/x-patch, attachment)]

Message #28 received at 58960-done <at> debbugs.gnu.org (full text, mbox):

From: Tino Calancha <tino.calancha <at> gmail.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: gerd.moellmann <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>,
 58960-done <at> debbugs.gnu.org, Robert Pluim <rpluim <at> gmail.com>,
 tino.calancha <at> gmail.com
Subject: Re: bug#58960: 29.0.50; Assert fails when browsing an URL, bug#58960:
 29.0.50; Assert fails when browsing an URL
Date: Thu, 3 Nov 2022 04:00:26 +0100 (CET)

On Wed, 2 Nov 2022, Paul Eggert wrote:


> child_signal_init is reasonably heavyweight in that it keeps a couple of file 
> descriptors open, so the idea is to be lazy and not call it unless Emacs 
> plans to have children.
>
> I installed the attached, which is like Robert's patch except it keeps the 
> critical section smaller and checks the declaration of the now-extern 
> function. Please give it a try. I'll boldly close the bug report; we can 
> reopen it if I'm wrong.

I have applied your patch; it fixes the issue.
Thank you.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Tino Calancha <tino.calancha <at> gmail.com>
Cc: gerd.moellmann <at> gmail.com, 58960 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>, Paul Eggert <eggert <at> cs.ucla.edu>
Subject: Re: bug#58960: 29.0.50; Assert fails when browsing an URL,
 bug#58960: 29.0.50; Assert fails when browsing an URL
Date: Thu, 03 Nov 2022 09:41:20 +0100

>>>>> On Thu, 3 Nov 2022 04:00:26 +0100 (CET), Tino Calancha <tino.calancha <at> gmail.com> said:

    Tino> On Wed, 2 Nov 2022, Paul Eggert wrote:


    >> child_signal_init is reasonably heavyweight in that it keeps a
    >> couple of file descriptors open, so the idea is to be lazy and not
    >> call it unless Emacs plans to have children.
    >>

Sure. Calling it from `init_process_emacs' works as well, but then
thereʼs some scary looking "if (!will_dump_with_unexec_p ())", so
letʼs not go there :-)

    >> I installed the attached, which is like Robert's patch except it
    >> keeps the critical section smaller and checks the declaration of the
    >> now-extern function. Please give it a try. I'll boldly close the bug
    >> report; we can reopen it if I'm wrong.

    Tino> I have applied your patch; it fixes the issue.
    Tino> Thank you.

Works for me as well, thanks Paul

Robert
-- 

Previous Next

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