A frame should not be made just to be deleted (exposes bug on emacs-mac build)

[jdtsmith]

Obviously my build (emacs-mac) shouldn't be crashing, but this is repeatable:

• Load activities
• M-x activities-discard (without an active activity)
• Select one of the saved activities
• Crash (from traceback, likely related to frame close)

Perhaps non-existent frames are being closed when a discarded activity is not actually active? Activating first then discarding works fine.

[alphapapa]

Please provide the backtrace.

[jdtsmith]

It's a hard crash so there is no Elisp back trace available. Here are the choice bits of the stack trace for the lisp thread:

0   libsystem_kernel.dylib        	       0x180b697f0 semaphore_wait_trap + 8
1   libdispatch.dylib             	       0x1809f8eac _dispatch_sema4_wait + 28
2   libdispatch.dylib             	       0x1809f955c _dispatch_semaphore_wait_slow + 132
3   Emacs                         	       0x101090e24 mac_within_gui_and_here + 148 (macappkit.m:16620)
4   Emacs                         	       0x101078228 mac_within_gui + 12 (macappkit.m:16599) [inlined]
5   Emacs                         	       0x101078228 mac_dispose_frame_window + 80 (macappkit.m:5372)
6   Emacs                         	       0x101031c60 mac_free_frame_resources + 212 (macterm.c:4404)
7   Emacs                         	       0x1010380dc mac_destroy_window + 12 (macterm.c:4445)
8   Emacs                         	       0x100de8cb8 delete_frame + 3104 (frame.c:2255)
9   activities-021b7cf9-abcc5ed9.eln	       0x1305dbfdc F616374697669746965732d636c6f7365_activities_close_0 + 76
10  Emacs                         	       0x100f842c4 funcall_subr_1 + 128 (eval.c:3045) [inlined]
11  Emacs                         	       0x100f842c4 __funcall_subr_block_invoke + 324 (eval.c:3090)
12  Emacs                         	       0x10106c464 mac_autorelease_loop + 48 (macappkit.m:911)
13  Emacs                         	       0x100f839bc funcall_subr + 88 (eval.c:3089) [inlined]
14  Emacs                         	       0x100f839bc funcall_general + 680 (eval.c:2947)
15  Emacs                         	       0x100f7f718 Ffuncall + 440 (eval.c:3001)

[jdtsmith]

Selecting a non-active activity for discarding seems to lead to an "empty" activity. A simpler crash reproducer is

(activities-close (make-activities-activity :name "tmp"))

[alphapapa]

Thanks. What Emacs version and where is the build from?

[jdtsmith]

This is emacs-mac, my own build based on 29.2. The real issue is that an empty activity has an empty frame, but activities--switch will make a new frame (with no real parameters) if such an empty activity is encountered.

On further investigation, this is the deadly pattern we must avoid:

(progn (select-frame (make-frame)) (delete-frame))

Obviously this should not crash and I've submitted this as a bug upstream, but discarding a non-activated activity should not need or attempt to create a frame for it. activities-close is where the just created null frame is deleted.

[alphapapa]

Ok. Would you please link the bug here for future reference?

[jdtsmith]

Thanks. I'm afraid emacs-mac does not use a bug tracker. Here's what I reported:

Deleting a newly selected frame crashes emacs-mac:
(progn (select-frame (make-frame)) (delete-frame))
GNU Emacs 29.1.90 (build 5, aarch64-apple-darwin23.2.0, Carbon Version 170 AppKit 2487.3) of 2024-01-11

[alphapapa]

So you're saying that you're using an unofficial, third-party build of Emacs?

[jdtsmith]

Not exactly, the history is complicated. See this README. This is one of the most used ports on Mac.

[alphapapa]

That's a bit too complicated for me to digest. :) Anyway, evaluating this does no harm on Emacs 29.1 on Linux: (progn (select-frame (make-frame)) (delete-frame)). But it doesn't make sense to do that, so I'll try to fix it...

[alphapapa]

I think that should fix it. I also added a confirmation prompt. Please let me know if the problem happens again.