bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#24472:


From: Marc Herbert
Subject: bug#24472:
Date: Tue, 28 Apr 2020 20:21:21 -0700

I've been stuck with emacs 26.1 for a long time because of this bug.
On my systems versions 26.2 and above all crash like this. I saw it
consistently across multiple macOS versions up to Mojave, but only
with Emacs 26.2 and up, never with 26.1

I got tired of this crash and just did some investigation, hope you
find it interesting.

I downgraded and upgraded tramp in 26.1 and 26.1 still doesn't crash,
on my system the tramp version doesn't make any difference. Only the
Emacs version does.

HOWEVER, even with 26.1 that does NOT crash, I always observe a small
< 0.5s but visible delay when opening menus. Worse: sometimes the
menus don't open at all! The click is acknowledged by the inversion of
the menu name but nothing unfolds underneath.

This delay and sometimes missing menus happen only when the current
buffer of the current frame is a tramp buffer. Switch the top frame to
a local file and everything is fine again. So I fired up Wireshark and
as expected I saw some ssh traffic when opening the 26.1 menus with a
tramp buffer.

[Bonus question: Apple cares about latency. Does macOS allow
networking while merely trying to open a menu?]

Now this is where I find things get really interesting:

On my system,
 - with 26.1, the "Apple" and "Emacs" menus don't cause any network
traffic or lag. All other menus do.
 - with 26.2 and above, the "Apple" and "Emacs" menus don't cause any
crash.     All other menus do.

Coincidence? Mmmm....

With 26.2, the same sort of ssh traffic is visible right before the crash.

My guess is some timeout that cancels rendering the menu if it takes
too long with 26.1. Could the same timeout cause the crash with 26.2
and above? For instance because this timeout.... already released the
resource that Emacs tries to release _again_?

If you can't reproduce but would like to: adding small delays in the
code is the simplest way to make race conditions like this one more
deterministic.

Interestingly, this similar crash
https://github.com/polymode/poly-R/issues/15 seems to also happen
because of a "too fancy menu". Stay tuned.


Version 27.0.90

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        0x00007fff58dcd2c2 __pthread_kill + 10
1   libsystem_pthread.dylib        0x00007fff58e88bf1 pthread_kill + 284
2   libsystem_c.dylib              0x00007fff58cead8a raise + 26
3   Emacs-x86_64-10_14            0x00000001014eefb9
terminate_due_to_signal + 153
4   Emacs-x86_64-10_14            0x00000001014ef8fb emacs_abort + 15
5   Emacs-x86_64-10_14            0x00000001014b71b0 ns_term_shutdown + 80
6   Emacs-x86_64-10_14            0x0000000101399064 shut_down_emacs + 340
7   Emacs-x86_64-10_14            0x00000001014eef86
terminate_due_to_signal + 102
8   Emacs-x86_64-10_14            0x00000001013b98be handle_fatal_signal + 14
9   Emacs-x86_64-10_14            0x00000001013b9941 deliver_thread_signal + 129
10  Emacs-x86_64-10_14            0x00000001013b8399
deliver_fatal_thread_signal + 9
11  libsystem_platform.dylib      0x00007fff58e7db5d _sigtramp + 29
12  com.apple.CoreFoundation      0x00007fff2ccdbd9a _CFAutoreleasePoolPop + 22
13  libsystem_kernel.dylib        0x00007fff58de0585 abort_with_reason + 22
14  libobjc.A.dylib                0x00007fff574c58dd
_objc_fatalv(unsigned long long, unsigned long long, char const*,
__va_list_tag*) + 108
15  libobjc.A.dylib                0x00007fff574c578f _objc_fatal(char
const*, ...) + 135
16  libobjc.A.dylib                0x00007fff574b8563 (anonymous
namespace)::AutoreleasePoolPage::pop(void*) + 941
17  com.apple.CoreFoundation      0x00007fff2ccdbd9a _CFAutoreleasePoolPop + 22
18  com.apple.Foundation          0x00007fff2ef560b3
-[NSAutoreleasePool release] + 144
19  Emacs-x86_64-10_14            0x00000001014d1992 ns_update_menubar + 2274
20  Emacs-x86_64-10_14            0x00000001014d19ce ns_activate_menubar + 14
21  Emacs-x86_64-10_14            0x00000001013a25ce read_char + 8846
22  Emacs-x86_64-10_14            0x000000010139e7aa read_key_sequence + 1722
23  Emacs-x86_64-10_14            0x000000010139cfac command_loop_1 + 1340
24  Emacs-x86_64-10_14            0x0000000101423b87
internal_condition_case + 263
25  Emacs-x86_64-10_14            0x00000001013ad120 command_loop_2 + 48
26  Emacs-x86_64-10_14            0x00000001014233ab internal_catch + 267
27  Emacs-x86_64-10_14            0x00000001014ef385 command_loop.cold.1 + 69
28  Emacs-x86_64-10_14            0x000000010139c073 command_loop + 131
29  Emacs-x86_64-10_14            0x000000010139bfa3 recursive_edit_1 + 115
30  Emacs-x86_64-10_14            0x000000010139c1fb Frecursive_edit + 347
31  Emacs-x86_64-10_14            0x000000010139add7 main + 7431
32  libdyld.dylib                  0x00007fff58c923d5 start + 1





reply via email to

[Prev in Thread] Current Thread [Next in Thread]