bug#37299: 26.3; Emacs on OSX crashes when clicking menu items while using tramp

[Robert Pluim <rpluim@gmail.com>]

>>>>> On Wed, 04 Sep 2019 22:09:35 +0200, Michael Albinus <michael.albinus@gmx.de> said:

    Michael> Robert Pluim <rpluim@gmail.com> writes:
    Michael> Hi Robert,

    Michael> Unfortunately, there's no solution yet. Personally, I
    Michael> don't use macOS,
    Michael> so I cannot investigate.
    >> 
    >> Iʼve stared at the code, and I canʼt see anything wrong with it. What
    >> kind of debug would you want?

    Michael> Nothing, because I believe it is rather an error related to macOS. Tramp
    Michael> is just the trigger, but I cannot see any reason how Tramp could trigger
    Michael> Emacs to crash.

    Michael> Maybe you try to reproduce the problem, and check the traces in gdb then?

I can reproduce it, but it doesnʼt really help:

* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x00007fff5c41a016 libsystem_kernel.dylib`__abort_with_payload + 10
    frame #1: 0x00007fff5c4155db libsystem_kernel.dylib`abort_with_payload_wrapper_internal + 82
    frame #2: 0x00007fff5c415589 libsystem_kernel.dylib`abort_with_reason + 22
    frame #3: 0x00007fff5aafb8dd libobjc.A.dylib`_objc_fatalv(unsigned long long, unsigned long long, char const*, __va_list_tag*) + 108
    frame #4: 0x00007fff5aafb78f libobjc.A.dylib`_objc_fatal(char const*, ...) + 135
    frame #5: 0x00007fff5aaee563 libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 941
    frame #6: 0x00007fff303415ea CoreFoundation`_CFAutoreleasePoolPop + 22
    frame #7: 0x00007fff325ba0e3 Foundation`-[NSAutoreleasePool release] + 144
    frame #8: 0x00000001001e8635 emacs`ns_update_menubar(f=<unavailable>, deep_p=<unavailable>, submenu=<unavailable>) at nsmenu.m:0:5 [opt]
    frame #9: 0x00000001001e867e emacs`ns_activate_menubar(f=<unavailable>) at nsmenu.m:476:3 [opt]
    frame #10: 0x00000001000c880e emacs`read_char at keyboard.c:3894:6 [opt]
    frame #11: 0x00000001000c7ff8 emacs`read_char [inlined] read_event_from_main_queue(end_time=0x0000000000000000, local_getcjmp=0x00000001051ba0a0, used_mouse_menu=0x00007ffeefbff1db) at keyboard.c:2136 [opt]
    frame #12: 0x00000001000c7e88 emacs`read_char at keyboard.c:2200 [opt]
    frame #13: 0x00000001000c7e4d emacs`read_char(commandflag=1, map=0x00000001039609a3, prev_event=0x0000000000000000, used_mouse_menu=0x00007ffeefbff1db, end_time=0x0000000000000000) at keyboard.c:2808 [opt]
    frame #14: 0x00000001000c4b1b emacs`read_key_sequence(keybuf=<unavailable>, prompt=0x0000000000000000, dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=<unavailable>) at keyboard.c:9125:12 [opt]
    frame #15: 0x00000001000c32dc emacs`command_loop_1 at keyboard.c:1345:15 [opt]
    frame #16: 0x000000010014a029 emacs`internal_condition_case(bfun=(emacs`command_loop_1 at keyboard.c:1236), handlers=0x0000000000000090, hfun=<unavailable>) at eval.c:1355:25 [opt]
    frame #17: 0x00000001000d25b0 emacs`command_loop_2(ignore=<unavailable>) at keyboard.c:1091:11 [opt]
    frame #18: 0x00000001001496f7 emacs`internal_catch(tag=0x000000000000c4b0, func=(emacs`command_loop_2 at keyboard.c:1087), arg=0x0000000000000000) at eval.c:1116:25 [opt]
    frame #19: 0x00000001000c22ee emacs`command_loop at keyboard.c:1070:2 [opt]
    frame #20: 0x00000001000c2203 emacs`recursive_edit_1 at keyboard.c:714:9 [opt]
    frame #21: 0x00000001000c24ab emacs`Frecursive_edit at keyboard.c:786:3 [opt]
    frame #22: 0x00000001000c0bd2 emacs`main(argc=<unavailable>, argv=0x00007ffeefbff668) at emacs.c:2086:3 [opt]
    frame #23: 0x00007fff5c2c73d5 libdyld.dylib`start + 1
    frame #24: 0x00007fff5c2c73d5 libdyld.dylib`start + 1

Which just tells us that

  /* set main menu */
  if (needsSet)
    [NSApp setMainMenu: menu];

  [pool release]; <= This causes the crash
  unblock_input ();

but not what object is at fault. Removing that [pool release] fixes
the crash, but probably means leaking memory.

Robert