From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: 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 Message-ID: <83k04d9yva.fsf@gnu.org> References: <87k04dodxs.fsf@gmail.com> <83wn8da4eo.fsf@gnu.org> <87zgd9mpa8.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14002"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, 58960@debbugs.gnu.org, tino.calancha@gmail.com To: Robert Pluim , eggert@cs.ucla.edu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 02 16:11:23 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oqFOl-0003Pk-E3 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 02 Nov 2022 16:11:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oqFOU-0004Iq-7L; Wed, 02 Nov 2022 11:11:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqFOR-0004IF-KC for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 11:11:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oqFOR-0000o3-A7 for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 11:11:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oqFOQ-0007TH-GA for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 11:11:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Nov 2022 15:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58960 X-GNU-PR-Package: emacs Original-Received: via spool by 58960-submit@debbugs.gnu.org id=B58960.166740180728651 (code B ref 58960); Wed, 02 Nov 2022 15:11:02 +0000 Original-Received: (at 58960) by debbugs.gnu.org; 2 Nov 2022 15:10:07 +0000 Original-Received: from localhost ([127.0.0.1]:46972 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oqFNW-0007S3-JY for submit@debbugs.gnu.org; Wed, 02 Nov 2022 11:10:06 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:57548) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oqFNU-0007RQ-OJ for 58960@debbugs.gnu.org; Wed, 02 Nov 2022 11:10:05 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqFNO-0000Nc-KH; Wed, 02 Nov 2022 11:09:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=jWgGMbdNhES3M38CDgoIEOfPYDLySsh+uhPT3hdpXYk=; b=Wob/K/ek/lU1IxF96Puc fyGGtyRW0Y1qBqTrxeuplHV7OxCdjqYz/TPT6f0hVfhFMFu955AK8Moka+/l1SR6kS+IlZZQrEaLN Qsmlteraoqz1G3HRPSahawyb4IS+pjhFbqMHKiirziR9B/M9zOi/Ok96pXqiT92D6YgmtBo6daUZt q+UaO7agSr9tospyoRzDUnVlXRMMlYf0/K/d0DGwbt90Lgl0ceqfCSLJit5vNnE+tPoL5eZqG/jPt wmjLx13/LS+mcogj4CncVxOy4n9NgzGp5SQpdLx8Bem7ATi2tu+5tqqcuHjS/rx5vow07/HS9hMWm zmIm7FiNyB+8BA==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oqFNN-0002XE-Tu; Wed, 02 Nov 2022 11:09:58 -0400 In-Reply-To: <87zgd9mpa8.fsf@gmail.com> (message from Robert Pluim on Wed, 02 Nov 2022 14:58:23 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "bug-gnu-emacs" Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:246877 Archived-At: > From: Robert Pluim > Cc: Paul Eggert , tino.calancha@gmail.com, > gerd.moellmann@gmail.com, 58960@debbugs.gnu.org > Date: Wed, 02 Nov 2022 14:58:23 +0100 > > >>>>> On Wed, 02 Nov 2022 15:10:07 +0200, Eli Zaretskii said: > > >> Cc: Gerd Möllmann , > >> 58960@debbugs.gnu.org > >> From: Robert Pluim > >> 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@entry=0x5555558d938f "0 <= fd", file=file@entry=0x5555558d9354 "process.c", line=line@entry=7386) at alloc.c:7692 > #2 0x00005555555bfec9 in child_signal_notify () at process.c:7386 > #3 handle_child_signal (sig=) at process.c:7493 > #4 0x000055555574e992 in deliver_process_signal > (sig=17, handler=0x555555831b40 ) at sysdep.c:1741 > #5 0x00007ffff5752140 in () > > `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?