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

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Alan Third <alan@idiocy.org> writes:

> Is this the same error as above, with the corrupt autorelease pool?

Probably not, one being an ABRT, and one a SEGV.  Or maybe they are,
if the underlying cause is the same.

It's all pretty strange.  Maybe it's a timing thing?  I mean, ignoring
the possibility of an optimization bug for a moment, the fact that
optimization flags that make Emacs slower make the bug disappear.  Or
the fact that it takes a "random" number of runs to make it happen.  And
that it doesn't happen at all on my old Macbook, which is 2x or so
slower than my M1 Mac mini.  I wouldn't be surprised if Christian had an
even faster CPU, so that he sees the bug more reliably.

Out of curiosity, Christian, what CPU do you have?

>>     frame #27: 0x00000001a9b12b18 AppKit`-[NSApplication(NSEvent)
>> _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 716
>>     frame #28: 0x000000010052e0d4 emacs`ns_send_appdefined(value=-1) at nsterm.m:4569:24 [opt]
>
> This is an interesting little bit of code with a comment saying it's
> been added to cover for what sounds like a bug in macOS 10.10...
> Perhaps it's worth removing it and seeing if that helps.
>
> The code's around nsterm.m line 4569, and the whole #ifdef'd section
> should be removed.
>

Thanks, I'll try that.

diff --git a/src/nsterm.m b/src/nsterm.m
index c809c0b824a..2cb508b5328 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -4560,6 +4560,7 @@ Function modeled after x_draw_glyph_string_box ().
      the [NXApp run] main loop after having processed all events queued at
      this moment.  */
 
+#if 0
 #ifdef NS_IMPL_COCOA
   if (! send_appdefined)
     {
@@ -4572,6 +4573,7 @@ in certain situations (rapid incoming events).
                                             dequeue:NO];
       if (! appev) send_appdefined = YES;
     }
+#endif
 #endif
 
   if (send_appdefined)

> I still suspect that if we have a corrupt autorelease pool, the
> problem will be somewhere entirely different...

Yeah.  Strange thing is that ASAN doesn't kick in.  Hm.  Maybe Apple has
something for debugging such situations?  I guess it's worth googling.