From: Marc Herbert <marc.herbert@gmail.com>
To: 24472@debbugs.gnu.org
Subject: bug#24472:
Date: Tue, 28 Apr 2020 20:21:21 -0700 [thread overview]
Message-ID: <CA+rkZbiFZOKqGmA0HkYJ8Nb0Sd8aqx5GuGhT0ipgJSk8MtUg0A@mail.gmail.com> (raw)
In-Reply-To: <766BC176-2ACE-410B-A438-938353499533@gmail.com>
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
next prev parent reply other threads:[~2020-04-29 3:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-19 19:47 bug#24472: 25.1; Emacs crashes when clicking on OSX menu bar when opening file with tramp Souvik Banerjee
2016-09-28 21:34 ` Alan Third
2018-09-28 13:34 ` bug#24472: " Darren Kenny
2020-04-29 3:21 ` Marc Herbert [this message]
2020-04-29 7:39 ` bug#24472: Eli Zaretskii
[not found] ` <CA+rkZbjtj=K4dCmWvGZ3ovi1JH9ddbeLgJofScG7w+tF9Rs=Sg@mail.gmail.com>
2020-04-29 14:42 ` bug#24472: Eli Zaretskii
[not found] ` <CA+rkZbhT2tkaHToLbyzHtReBxqKRVQ3woBNnSnNWfoLGSh9iMQ@mail.gmail.com>
2020-04-29 15:01 ` bug#24472: Eli Zaretskii
2020-05-01 8:47 ` bug#24472: - a workaround/fix for the menubar crashes on macOS Marc Herbert
2020-05-02 0:14 ` Marc Herbert
2020-05-02 7:33 ` Marc Herbert
2020-05-02 12:15 ` Michael Albinus
2020-05-02 12:18 ` Eli Zaretskii
2020-05-01 20:11 ` bug#24472: PATCH * tramp-cache.el: tweak debug log to include cache hit info Marc Herbert
2020-05-02 11:32 ` Michael Albinus
2020-05-02 17:04 ` Marc Herbert
2020-05-02 17:48 ` Noam Postavsky
2020-05-03 12:02 ` Michael Albinus
2020-05-03 12:13 ` Michael Albinus
2020-05-03 12:14 ` Michael Albinus
2020-05-03 12:22 ` Michael Albinus
2020-05-21 18:50 ` bug#24472: (no subject) Marc Herbert
2020-05-22 20:47 ` Alan Third
2021-01-02 22:39 ` bug#24472: 25.1; Emacs crashes when clicking on OSX menu bar when opening file with tramp Alan Third
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CA+rkZbiFZOKqGmA0HkYJ8Nb0Sd8aqx5GuGhT0ipgJSk8MtUg0A@mail.gmail.com \
--to=marc.herbert@gmail.com \
--cc=24472@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).