bug#63495: 28.2; menu crashes on macos

[Alan Third]

On Wed, Jul 12, 2023 at 08:44:04PM +0300, Eshel Yaron wrote:
> Alan Third <alan@idiocy.org> writes:
> 
> >> > There's nothing obvious in that function that would be doing that,
> >> > so it would be good if we could get a backtrace from a debugger
> >> > showing the exact line that's causing the problem and, if possible,
> >> > which variable has the value 3.
> >> 
> >> There's this backtrace that I've posted in Bug#62402, HTH:
> >> 
> >> > * thread #1, queue = 'com.apple.main-thread', stop reason = 
> >> > EXC_BAD_ACCESS (code=1, address=0x3)
> >> >   * frame #0: 0x00000001000aebad emacs`AREF(array=0x0000000000000000, 
> >> > idx=0) at lisp.h:1947:10
> >> >     frame #1: 0x00000001000af660 
> >> > emacs`find_and_return_menu_selection(f=0x00000001100dee30, keymaps=true, 
> >> > client_data=0x000000011089b888) at menu.c:985:11
> >> >     frame #2: 0x0000000100380f2b emacs`-[EmacsMenu 
> >> > runMenuAt:forFrame:keymaps:](self=0x00006000017007c0, 
> >> > _cmd="runMenuAt:forFrame:keymaps:", p=(x = 2, y = 506), 
> >> > f=0x00000001100dee30, keymaps=true) at nsmenu.m:767:9
> >> >     frame #3: 0x0000000100381f00 
> >> > emacs`ns_menu_show(f=0x00000001100dee30, x=2, y=2, menuflags=1, 
> >> > title=0x0000000000000000, error=0x00007ff7bfefce80) at nsmenu.m:1067:9
> >> >     frame #4: 0x00000001000b1203 
> >> > emacs`x_popup_menu_1(position=0x000000011804dcb3, 
> >> > menu=0x000000011804e003) at menu.c:1410:17
> >> >     frame #5: 0x00000001000b15a2 
> >> > emacs`Fx_popup_menu(position=0x000000011804dcb3, 
> >> > menu=0x000000011804e003) at menu.c:1474:10
> >> >     frame #6: 0x0000000100247c58 emacs`eval_sub(form=0x000000011804dd23) 
> >> > at eval.c:2503:15
> >> >     ...
> >> > 
> >> > It seems that `find_and_return_menu_selection` in menu.c tries to
> >> > access the global variable `menu_items` before it's initialized.  I'm
> >> > not sure when or where it should be initialized though :(
> >
> > No, sorry, I need the output from a debugger. That should give the
> > exact line where the failure happens.
> 
> I'm not sure I understand, this *is* the output from a debugger.  I ran
> Emacs under lldb and got the above backtrace when it crashed.  It also
> includes the exact line number(s).  What am I missing?

Sorry, I misunderstood what I was looking at.

Can you please try this:

modified   src/nsmenu.m
@@ -746,6 +746,8 @@ - (Lisp_Object)runMenuAt: (NSPoint)p forFrame: (struct 
frame *)f
   NSEvent *e, *event;
   long retVal;
 
+  needsUpdate = NO;
+
   /* p = [view convertPoint:p fromView: nil]; */
   p.y = NSHeight ([view frame]) - p.y;
   e = [[view window] currentEvent];

At a guess, when the menu opens the first thing AppKit does is check if
it needs updated, and since a new menu starts with needsUpdate=YES, it
goes ahead and tries to do it, which overwrites some important
variables from the original "build" of the menu.

The context menu is built and then displayed, as opposed to the
top-menu that is partially built, then when it's to be displayed is
updated and filled in.
-- 
Alan Third