bug#37671: 27.0.50; Segmentation fault with --fg-daemon on Linux

[Frank Terbeck]

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