[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#37299: 26.3; Emacs on OSX crashes when clicking menu items while usi
From: |
Robert Pluim |
Subject: |
bug#37299: 26.3; Emacs on OSX crashes when clicking menu items while using tramp |
Date: |
Thu, 05 Sep 2019 11:33:20 +0200 |
>>>>> 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