From: Aaron Jensen <aaronjensen@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Eshel Yaron <me@eshelyaron.com>,
63988@debbugs.gnu.org, monnier@iro.umontreal.ca
Subject: bug#63988: 30.0.50; Recent header line format changes cause spin/seg fault with format-mode-line
Date: Thu, 15 Jun 2023 22:30:22 -0400 [thread overview]
Message-ID: <CAHyO48xdA+aCqHnZAyaE85KXqmYHXurqL5VJuQbz67cz=bBudg@mail.gmail.com> (raw)
In-Reply-To: <83y1kltgeq.fsf@gnu.org>
On Thu, Jun 15, 2023 at 1:58 AM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Eshel Yaron <me@eshelyaron.com>
> > Cc: aaronjensen@gmail.com, 63988@debbugs.gnu.org, Stefan Monnier
> > <monnier@iro.umontreal.ca>
> > Date: Sat, 10 Jun 2023 12:07:22 +0300
> >
> > > So maybe we should declare this feature a failed experiment and remove
> > > it?
> >
> > FWIW I think that make sense, but IMO it'd be best to only remove the
> > treatment of `:eval` in `window_wants_header_line`, and keep the new
> > treatment of `header-line-format` being a cons cell with a void or
> > nil-valued variable car. That's still useful because it works well with
> > minor mode variables, and it's less risky as it doesn't involve
> > evaluating arbitrary lisp, just inspecting a variable.
>
> Why would it make sense to leave the non-nil car case?
>
> It sounds like the consensus here is that indeed this feature is not
> worth the complications, and so, unless I hear some good reasons not
> to do so, I intend to delete it in a week's time.
I strongly support this. It's a major performance regression for me
and it seems to correspond with crashes on window resizing:
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 libsystem_kernel.dylib 0x191054724 __pthread_kill + 8
1 libsystem_pthread.dylib 0x19108bc28 pthread_kill + 288
2 libsystem_c.dylib 0x190f6246c raise + 32
3 Emacs 0x100a215b0
terminate_due_to_signal + 212
4 Emacs 0x100a21dfc emacs_abort + 20
5 Emacs 0x1009f0594 ns_term_shutdown + 132
6 Emacs 0x1008dcc90 shut_down_emacs + 332
7 Emacs 0x100a21578
terminate_due_to_signal + 156
8 Emacs 0x1008fd4bc
deliver_fatal_thread_signal + 128
9 Emacs 0x1008fee80 handle_sigsegv + 64
10 libsystem_platform.dylib 0x1910baa24 _sigtramp + 56
11 Emacs 0x10083a90c start_display + 56
12 Emacs 0x10085010c try_window + 144
13 Emacs 0x10086c88c display_echo_area_1 + 136
14 Emacs 0x1008496dc
with_echo_area_buffer + 784
15 Emacs 0x1008485bc echo_area_display + 268
16 Emacs 0x1008483bc message3_nolog + 548
17 Emacs 0x100847f5c message3 + 132
18 Emacs 0x100952470 Fmessage + 68
19 Emacs 0x100958074 eval_sub + 1980
20 Emacs 0x10095824c Fprogn + 48
21 Emacs 0x10095d728 funcall_lambda + 1276
22 Emacs 0x10095c284 apply_lambda + 280
23 Emacs 0x100957da8 eval_sub + 1264
24 Emacs 0x1009581c8 Fand + 60
25 Emacs 0x100957f7c eval_sub + 1732
26 Emacs 0x1009593f0 FletX + 268
27 Emacs 0x100957f7c eval_sub + 1732
28 Emacs 0x100957ed0 eval_sub + 1560
29 Emacs 0x100957ed0 eval_sub + 1560
30 Emacs 0x100957ed0 eval_sub + 1560
31 Emacs 0x10095824c Fprogn + 48
32 Emacs 0x10095d728 funcall_lambda + 1276
33 Emacs 0x10095c284 apply_lambda + 280
34 Emacs 0x100957da8 eval_sub + 1264
35 Emacs 0x10095974c Flet + 316
36 Emacs 0x100957f7c eval_sub + 1732
37 Emacs 0x100958034 eval_sub + 1916
38 Emacs 0x10095824c Fprogn + 48
39 Emacs 0x10095d728 funcall_lambda + 1276
40 Emacs 0x100959dc8 Ffuncall + 316
41 Emacs 0x100958074 eval_sub + 1980
42 Emacs 0x10095824c Fprogn + 48
43 Emacs 0x100957f7c eval_sub + 1732
44 Emacs 0x10095824c Fprogn + 48
45 Emacs 0x10095d728 funcall_lambda + 1276
46 Emacs 0x100959dc8 Ffuncall + 316
47 Emacs 0x1009677d4 mapcar1 + 328
48 Emacs 0x1009675b4 Fmapconcat + 460
49 Emacs 0x1009580d8 eval_sub + 2080
50 Emacs 0x1009593f0 FletX + 268
51 Emacs 0x100957f7c eval_sub + 1732
52 Emacs 0x10095c070 Feval + 84
53 Emacs 0x100959dc8 Ffuncall + 316
54 Emacs 0x10095ab74
internal_condition_case_n + 156
55 Emacs 0x100842d84 safe__call + 296
56 Emacs 0x100842e40 safe__call1 + 36
57 Emacs 0x100842e68
safe_eval_inhibit_quit + 28
58 Emacs 0x10088d47c
null_header_line_format + 388
59 Emacs 0x100881800
window_wants_header_line + 296
60 Emacs 0x100839e0c window_box_height + 860
61 Emacs 0x100829838
required_matrix_height + 72
62 Emacs 0x100829908
allocate_matrices_for_window_redisplay + 148
63 Emacs 0x100823728 adjust_frame_glyphs + 88
64 Emacs 0x10088f638
Fset_window_configuration + 4068
65 tab-bar-f81d329c-3b6a0fc2.eln 0x107163bc8
F7461622d6261722d73656c6563742d746162_tab_bar_select_tab_0 + 868
66 Emacs 0x100959dc8 Ffuncall + 316
67 tab-bar-f81d329c-3b6a0fc2.eln 0x1071641d4
F7461622d6261722d7377697463682d746f2d6e6578742d746162_tab_bar_switch_to_next_tab_0
+ 260
68 Emacs 0x100959dc8 Ffuncall + 316
69 Emacs 0x10095592c
Ffuncall_interactively + 68
70 Emacs 0x100959dc8 Ffuncall + 316
71 Emacs 0x100956a08 Fcall_interactively + 4292
72 simple-fab5b0cf-e1c8f2a9.eln 0x102b54b0c
F636f6d6d616e642d65786563757465_command_execute_0 + 652
next prev parent reply other threads:[~2023-06-16 2:30 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-10 1:09 bug#63988: 30.0.50; Recent header line format changes cause spin/seg fault with format-mode-line Aaron Jensen
2023-06-10 6:47 ` Eli Zaretskii
2023-06-10 8:56 ` Eli Zaretskii
2023-06-10 9:07 ` Eshel Yaron via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-15 5:59 ` Eli Zaretskii
2023-06-16 2:30 ` Aaron Jensen [this message]
2023-06-23 10:53 ` Eli Zaretskii
2023-07-05 15:30 ` Spencer Baugh
2023-07-05 15:40 ` Eli Zaretskii
2023-06-10 16:16 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-10 17:42 ` Eli Zaretskii
2023-06-10 17:51 ` Aaron Jensen
2023-06-10 19:11 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-06-10 11:08 ` Aaron Jensen
2023-06-10 11:22 ` Eli Zaretskii
2023-06-10 11:59 ` Aaron Jensen
2023-06-10 13:04 ` Eli Zaretskii
2023-06-10 15:06 ` Aaron Jensen
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='CAHyO48xdA+aCqHnZAyaE85KXqmYHXurqL5VJuQbz67cz=bBudg@mail.gmail.com' \
--to=aaronjensen@gmail.com \
--cc=63988@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=me@eshelyaron.com \
--cc=monnier@iro.umontreal.ca \
/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).