all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Christian Tanzer via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: "Gerd Möllmann" <gerd.moellmann@gmail.com>
Cc: Alan Third <alan@idiocy.org>, 65843@debbugs.gnu.org
Subject: bug#65843: 28.2; Too many iconified frames in .emacs.desktop -> crash (macOS)
Date: Sun, 10 Sep 2023 15:59:49 +0100	[thread overview]
Message-ID: <036BF52A-4EBC-4F33-8A52-7DF60F753A3D@gg32.com> (raw)
In-Reply-To: <m2zg1u4q2y.fsf@Pro.fritz.box>

[-- Attachment #1: Type: text/plain, Size: 3232 bytes --]

On 10.09.2023, at 05:20, Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
> 
>>> On Sat, Sep 09, 2023 at 04:35:56PM -0000, Christian Tanzer via Bug reports for GNU Emacs, the Swiss army knife of text editors wrote:
>>> 
>>> =============================================================================
>>> In Emacs 28 and Emacs 29, desktop-load crashes when there are too many
>>> iconified frames in the .emacs.desktop file.
>>> 
>>> The two attached .emacs.desktop files show the smallest test case that
>>> I could come up with:
>>> 
>>> - .emacs.desktop.works with 3 non-iconified and 4 iconified frames
>>>  loads without problem in Emacs 28
>>> 
>>>  + desktop-load of this file crashes in Emacs 29.1
>>> 
>>>  + a .emacs.desktop with 3 non-iconified and 3 iconified frames works
>>>    in Emacs 29.1
>>> 
>>> - .emacs.desktop.crashes with 3 non-iconified and 5 iconified frames
>>>  leads to a crash in Emacs 28 (see attached problem report generated
>>>  by macOS)
>>> 
>>> - I tried .emacs.desktop with up to 17 non-iconified frames in Emacs
>>>  28 without problems
>>> 
>>> - Up to Emacs 27, I've never seen a problem with desktop-load crashing
>>> =============================================================================
>> 
> Alas, I cannot reproduce the abort here, with an unpatched master or
> emacs-29, and neither on Ventura/arm64 nor Big Sur/x86_64 :-(.
> 
> Christian, can you reproduce this with emacs -Q?  Or does it perhaps
> depend on your init.el?  (This was the case for me in the child frane
> case that Alan fixed.)

Emacs29 -Q also crashes, but differently:

/Applications/Emacs-29.1.app/Contents/MacOS/Emacs --load=emacs28_desktop_load_init.el
    Fatal error 11: Segmentation fault
    Abort trap: 6

/Applications/Emacs-29.1.app/Contents/MacOS/Emacs -Q --load=emacs28_desktop_load_init.el
    objc[23222]: autorelease pool page 0x12a43c000 corrupted
      magic     0x2a05b000 0x00000001 0x000000eb 0x00000000
      should be 0xa1a1a1a1 0x4f545541 0x454c4552 0x21455341
      pthread   0x1e695e05d
      should be 0x1e695e080

    Fatal error 6: Aborted
    Abort trap: 6

with emacs28_desktop_load_init.el:

(setq desktop-path '("~/tmp/"))
(require 'desktop)
(desktop-read)

Emacs28 -Q doesn’t crash:

/Applications/Emacs-28.2.app/Contents/MacOS/Emacs --load=emacs28_desktop_load_init.el
    Fatal error 11: Segmentation fault
    Abort trap: 6

/Applications/Emacs-28.2.app/Contents/MacOS/Emacs -Q --load=emacs28_desktop_load_init.el
    ### no crash, desktop-read works

Weirder and weirder …

I tried to come up with a simpler desktop to trigger the crash, but 8 frames with the *scratch* buffer, 4 iconified, are not enough to trigger it. 

OTOH, opening two empty files 1 and 2 with 4 frames for each one and two frames of each file iconified triggers the crash in Emacs29 without the ‘-Q’, so only with my init-file involved.

Gerd, did you test with the .emacs.desktop files I attached to the bug report? My environment configures desktop-save to save iconified frames which standard Emacs doesn’t do. I have only seen crashes where there were more than 3 or 4 iconified frames in the .emacs.desktop.


[-- Attachment #2: Type: text/html, Size: 13024 bytes --]

  reply	other threads:[~2023-09-10 14:59 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-09 16:35 bug#65843: 28.2; Too many iconified frames in .emacs.desktop -> crash (macOS) Christian Tanzer via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-09 16:49 ` Eli Zaretskii
2023-09-09 17:36   ` Christian Tanzer via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-09 17:39     ` Eli Zaretskii
2023-09-10 14:11       ` Christian Tanzer via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-10 14:27         ` Eli Zaretskii
2023-09-10 15:07         ` Gerd Möllmann
2023-09-10 15:37           ` Christian Tanzer via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-10 16:04             ` Gerd Möllmann
2023-09-09 19:53 ` Alan Third
2023-09-10  4:20   ` Gerd Möllmann
2023-09-10 14:59     ` Christian Tanzer via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2023-09-10 15:37       ` Gerd Möllmann
2023-09-10 15:40         ` Christian Tanzer via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-10 17:09         ` Gerd Möllmann
2023-09-10 17:38           ` Gerd Möllmann
2023-09-10 17:09         ` Alan Third
2023-09-10 18:40           ` Gerd Möllmann
2023-09-10 19:54             ` Alan Third
2023-09-11  4:07               ` Gerd Möllmann
2023-09-11  4:50                 ` Gerd Möllmann
2023-09-11  7:55                   ` Christian Tanzer via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-11  8:06                     ` Gerd Möllmann
2023-09-11 16:25                       ` Alan Third
2023-09-11 17:16                         ` Christian Tanzer via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-11 18:26                           ` Alan Third
2023-09-12 17:43                             ` Christian Tanzer via Bug reports for GNU Emacs, the Swiss army knife of text editors

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=036BF52A-4EBC-4F33-8A52-7DF60F753A3D@gg32.com \
    --to=bug-gnu-emacs@gnu.org \
    --cc=65843@debbugs.gnu.org \
    --cc=alan@idiocy.org \
    --cc=gerd.moellmann@gmail.com \
    --cc=tanzer@gg32.com \
    /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.