GNU bug report logs - #65843
28.2; Too many iconified frames in .emacs.desktop -> crash (macOS)

Previous Next

Full log

View this message in rfc822 format

From: Christian Tanzer <tanzer <at> gg32.com>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Alan Third <alan <at> idiocy.org>, 65843 <at> 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

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

On 10.09.2023, at 05:20, Gerd Möllmann <gerd.moellmann <at> 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.

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

Previous Next

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