GNU bug report logs -
#37671
27.0.50; Segmentation fault with --fg-daemon on Linux
Previous Next
Reported by: Frank Terbeck <ft <at> bewatermyfriend.org>
Date: Wed, 9 Oct 2019 02:41:01 UTC
Severity: normal
Tags: moreinfo
Found in version 27.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Hello Eli!
Eli Zaretskii wrote:
[...]
>> (gdb) p w->current_matrix
>> $12 = (struct glyph_matrix *) 0x7a
>>
>> (gdb) p draw
>> $13 = DRAW_NORMAL_TEXT
>>
>> (gdb) p hlinfo->mouse_face_hidden
>> $14 = false
>>
>> (gdb) p hlinfo->mouse_face_end_row
>> $15 = 16
>>
>> (gdb) p w->current_matrix->nrows
>> Cannot access memory at address 0x92
>>
>> (gdb) p w->current_matrix
>> $17 = (struct glyph_matrix *) 0x7a
>
> This window is dead, AFAICT, and its memory has been recycled. So
> somehow we attempt to show mouse highlight on a deleted window or
> something. I have no idea how this could have happened.
>
> Moreover, the frame itself seems to have bogus values:
>
>> (gdb) p *f
>> $10 = {header = {size = 285941742698496},
>> name = 0x55573dc812400000,
>> icon_name = 0xfffffffffe000055,
>> title = 0xfffffffffeffffff,
>> parent_frame = 0xfffffffffeffffff,
>> focus_frame = 0xfffffffffeffffff,
>> root_window = 0xfffffffffeffffff,
>> selected_window = 0xfffffffffeffffff,
>> old_selected_window = 0xfffffffffeffffff,
>> minibuffer_window = 0xfffffffffeffffff,
>> param_alist = 0xfffffffffeffffff,
>> scroll_bars = 0xfffffffffeffffff,
>> condemned_scroll_bars = 0xfffffffffeffffff,
>> menu_bar_items = 0xfffffffffeffffff,
>> face_alist = 0xfffffffffeffffff,
>> menu_bar_vector = 0xfffffffffeffffff,
>> buffer_predicate = 0xfffffffffeffffff,
>> buffer_list = 0xfffffffffeffffff,
>> buried_buffer_list = 0xfffffffffeffffff,
>> tab_bar_window = 0xfffffffffeffffff,
>> desired_tab_bar_string = 0xfffffffffeffffff,
>> current_tab_bar_string = 0xfffffffffeffffff,
>> tool_bar_window = 0xfffffffffeffffff,
>> desired_tool_bar_string = 0xfffffffffeffffff,
>> current_tool_bar_string = 0xfffffffffeffffff,
>> font_data = 0xfffffffffeffffff,
>> tab_bar_items = 0xfffffffffeffffff,
>> tool_bar_items = 0xfffffffffeffffff,
>> face_cache = 0xfffffffffeffffff,
>> last_tab_bar_item = -16777217,
>> last_tool_bar_item = -1,
>> menu_bar_items_used = -16777217,
>> namebuf = 0xfffffffffeffffff <error: Cannot access memory at address 0xfffffffffeffffff>,
>> shell_position = 0xfffffffffeffffff <error: Cannot access memory at address 0xfffffffffeffffff>,
>
> What exactly did you do immediately prior to the crash?
I was reading mail using Gnus. When I do, with an article visible, gnus
is configured to show three windows (Group left of Summary and Article,
with Article below Summary). Then I switched the visible workspace in my
X11 window manager to somewhere emacs wasn't visible, switched back to
the workspace with emacs and that's when I had then unresponsive emacs
window sitting there, with gdb letting me know about the segfault.
I can't tell for sure, if the crash occurred before switching workspaces
or if that's what triggered it — but I *think* switching workspaces was
involved in past crashes as well. But maybe that's another coincidence.
I did not close an emacs frame, though. I am not sure what I did in Gnus
last. Could be, that I was in this article-viewing layout I described
above and selected another article from the summary buffer. That causes
Gnus to reuse the current article window to display the newly selected
one. I don't know if internally that involves closing windows etc.
Sadly, my brand-new Thinkpad thought a hard lock-up over night would be
great fun. Of course this happens when I just triggered something hard
to trigger. Sigh. The gdb session is gone with it. :-(
Anyway. I'm running my emacs inside gdb again, in case it happens again.
Let me know if I can be of further assistance.
Regards, Frank
This bug report was last modified 5 years and 81 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.