From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Aaron Jensen Newsgroups: gmane.emacs.bugs Subject: bug#60220: 29.0.60; macOS 13.1 crash shortly after starting Emacs Date: Tue, 20 Dec 2022 22:47:46 -0500 Message-ID: References: <83y1r2axrn.fsf@gnu.org> <83r0wuat1n.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31168"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 60220@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Dec 21 04:49:25 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 1p7q6e-0007rd-Iv for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 21 Dec 2022 04:49:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p7q6J-0005qQ-Vg; Tue, 20 Dec 2022 22:49:03 -0500 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 1p7q6I-0005qB-Sj for bug-gnu-emacs@gnu.org; Tue, 20 Dec 2022 22:49:02 -0500 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 1p7q6I-0008KG-Je for bug-gnu-emacs@gnu.org; Tue, 20 Dec 2022 22:49:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1p7q6I-0000hM-86 for bug-gnu-emacs@gnu.org; Tue, 20 Dec 2022 22:49:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Aaron Jensen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 21 Dec 2022 03:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60220 X-GNU-PR-Package: emacs Original-Received: via spool by 60220-submit@debbugs.gnu.org id=B60220.16715944862646 (code B ref 60220); Wed, 21 Dec 2022 03:49:02 +0000 Original-Received: (at 60220) by debbugs.gnu.org; 21 Dec 2022 03:48:06 +0000 Original-Received: from localhost ([127.0.0.1]:49015 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p7q5N-0000ga-MN for submit@debbugs.gnu.org; Tue, 20 Dec 2022 22:48:06 -0500 Original-Received: from mail-pl1-f173.google.com ([209.85.214.173]:33384) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1p7q5L-0000fb-F6 for 60220@debbugs.gnu.org; Tue, 20 Dec 2022 22:48:04 -0500 Original-Received: by mail-pl1-f173.google.com with SMTP id 17so14361826pll.0 for <60220@debbugs.gnu.org>; Tue, 20 Dec 2022 19:48:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=QzdEE4KorQ5j9nK4in5jRy22eFQHA8YQaJHlePuXO3s=; b=ng/rt56gpKAsS58tXgNrQEVNNzgFUidCPX52zrxTh0lVe33zGzZpp0NWS8wagWXn9J /UIIz7mXDfUpxCbTdTQsdag5tsaBGMqi8k36UO9P2Jb1gBqRqg91iPBkPFxDvBl5XUiS xnLFhnUqETo2j3GWLyBUteP8fJmWkS6wjlGoNcPrWlAGm6vuZALPmx8XkMpCrCDg/Ct9 WIOIDrKaVQxRqlYPnlbgL12RGRpwcdLH/6JnbUvGbs0OVBZnwdHnLSF16vhs2ZEmZeTu bvIUehat4JJqwnxv4Kbzo+IVLpAM0I98L0D90997avuRq0Bj2ot/8TzVeEyTuHoy1jMY os0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=QzdEE4KorQ5j9nK4in5jRy22eFQHA8YQaJHlePuXO3s=; b=Fl2jj4REXt1xLcFVwyMi6klBgvXsbmKBtXNwub9jbkuSzfM4v3IHyzbB9wcP1x8r0t Z4p7S75UgA16waZjVPsQjNDzeeI7dJy2ZIqLFeN+oT4xWM9g3goJ2J6YXrhmVMOht4j7 MTWEehTFE1nJjPYS/5/AqJDfkDNbZMyMg0FNJlE5WPnU0lRm7o9JLqTptRfpVhXrPhXc 7ZP0D2NuIUZ+RReFUjv1iVpP8IR7jHIariivzPsBpSPY3R08X3DerPQSv1KCq2J9UAR5 FKNKCywjsCybhwt0KFSoXbpQYGFQ+AgDQ4n7tkDwFICU5UGEUu/fn2fAcfAy24PnAfUZ giZQ== X-Gm-Message-State: AFqh2kr0otblZRfJwGXzumcUnOLgFSSm4jUlKj8UfczTviNP+DanxTAM dTBNrTgZRzUNz4M+7jOkdtkQ4qX84vyPTJKU4UY= X-Google-Smtp-Source: AMrXdXtJwMcRdb4rGxQdK7Iy2IVSw2pHJSj+bU8kGaut8xTt8FUE7T7UWqIMPfNPKfQIstLvGY3pzvt+5nv219uTTGs= X-Received: by 2002:a17:903:50e:b0:186:9c2b:3a39 with SMTP id jn14-20020a170903050e00b001869c2b3a39mr14220plb.115.1671594477388; Tue, 20 Dec 2022 19:47:57 -0800 (PST) In-Reply-To: <83r0wuat1n.fsf@gnu.org> 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: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:251557 Archived-At: On Tue, Dec 20, 2022 at 12:22 PM Eli Zaretskii wrote: > > > From: Aaron Jensen > > Date: Tue, 20 Dec 2022 10:59:20 -0500 > > Cc: 60220@debbugs.gnu.org > > > > On Tue, Dec 20, 2022 at 10:40 AM Eli Zaretskii wrote: > > > > > > AFAIU, it says that Emacs was _loading_ rng-loc. That doesn't mean > > > the problem is in rng-loc's code. The fatal signal comes from the > > > maxOS implementation of dlopen, so I suspect that the way we restart > > > Emacs messes up some OS data structures regarding loaded shared > > > libraries or something. > > > > > > Note that the previous crash you posted also crashes inside dlopen. > > > > > > So I think it's safe to say that restarting Emacs makes loading of > > > *.eln files (and maybe share libraries in general) fragile and tending > > > to crash, for some reason. Maybe we should explicitly unload all the > > > *.eln files when we restart? > > > > Interesting. If I restart while launched from lldb, I get the below. > > It happens right away and it doesn't actually restart. This is not the > > behavior I see if I launch it normally or in xcode. I should note that > > occasionally when I restart Emacs it just quits and does not restart. > > I have to restart it manually. Perhaps this is all connected to the > > issue you're suggesting. > > > > (lldb) process launch > > Process 19414 launched: 'src/emacs' (arm64) > > Process 19414 stopped > > * thread #8, stop reason = exec > > frame #0: 0x0000000100b2c950 dyld`_dyld_start > > dyld`: > > -> 0x100b2c950 <+0>: mov x0, sp > > 0x100b2c954 <+4>: and sp, x0, #0xfffffffffffffff0 > > 0x100b2c958 <+8>: mov x29, #0x0 > > 0x100b2c95c <+12>: mov x30, #0x0 > > Target 0: (emacs) stopped. > > (lldb) thread list > > Process 19414 stopped > > * thread #8: tid = 0x3026c, 0x0000000100b2c950 dyld`_dyld_start, stop > > reason = exec > > (lldb) thread backtrace > > * thread #8, stop reason = exec > > * frame #0: 0x0000000100b2c950 dyld`_dyld_start > > (lldb) continue > > Process 19414 resuming > > Process 19414 exited with status = 14 (0x0000000e) Terminated due to signal 14 > > What is "signal 14" on macOS? This is all I could find: 14 SIGALRM terminate process real-time timer expired I'm able to reproduce the above without native compilation as well. This particular thing only happens when in a lldb and doesn't affect me in practice. > Anyway, look at the code: we restart by calling execvp. You or > someone who knowns macOS internals should take a look at what that > means for shared libraries which were loaded by the program that calls > execvp -- what happens with those libraries in the execvp'ed process. > I'm guessing that they are not being unloaded and re-loaded by the new > process, or something to that effect. > > Or maybe the way we load the *.eln files causes this, triggered by > 'execvp'? This is out of my depth. I did a tiny bit of digging and didn't find anything. I'll keep looking but if someone is more familiar w/ this they'd have more luck than me I'm sure. > Can you try running for a while Emacs built without native compilation > and restarting it? That could tell us whether the *.eln files are the > problem. I wasn't able to reproduce it w/o native compilation. I'm going to try running w/ native compilation for a while *without* doing any restarts and see if I can get it to crash. I've seen crashes take an hour+ after a restart (though most happen w/in 30 seconds). I can't say definitively that all crashes have happened in a restarted process. Aaron