GNU bug report logs - #44506
28.0.50; Segfault on opening a particular message in Gnus in terminal/tty

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Amin Bandali <bandali <at> gnu.org>
Cc: eric <at> ericabrahamsen.net, 44506 <at> debbugs.gnu.org
Subject: bug#44506: 28.0.50; Segfault on opening a particular message in Gnus in terminal/tty
Date: Mon, 09 Nov 2020 09:04:58 +0200

On November 9, 2020 6:43:59 AM GMT+02:00, Amin Bandali <bandali <at> gnu.org> wrote:
> Eli Zaretskii writes:
> 
> [...]
> >
> > Thanks.  One more thing, and then I need to think how this could
> > happen:
> >
> >   (gdb) frame 3
> 
> #3  0x00005555555a000c in update_frame_line (f=0x555556113798,
> vpos=24, updating_menu_p=false) at dispnew.c:5089
> 
> >   
> >   (gdb) print (desired_row->glyphs[1])[149]
> >
> 
> $1 = {
>   charpos = -1,
>   object = XIL(0),
>   pixel_width = 0,
>   ascent = 0,
>   descent = 0,
>   voffset = 0,
>   type = 0,
>   multibyte_p = false,
>   left_box_line_p = false,
>   right_box_line_p = false,
>   overlaps_vertically_p = false,
>   padding_p = false,
>   glyph_not_available_p = false,
>   avoid_cursor_p = false,
>   resolved_level = 0,
>   bidi_type = 0,
>   face_id = 0,
>   font_type = 0,
>   slice = {
>     img = {
>       x = 0,
>       y = 0,
>       width = 0,
>       height = 0
>     },
>     cmp = {
>       from = 0,
>       to = 0
>     },
>     glyphless = {
>       upper_xoff = 0,
>       upper_yoff = 0,
>       lower_xoff = 0,
>       lower_yoff = 0
>     }
>   },
>   u = {
>     ch = 32,
>     cmp = {
>       automatic = false,
>       id = 16
>     },
>     img_id = 32,
>     stretch = {
>       height = 32,
>       ascent = 0
>     },
>     glyphless = {
>       method = 0,
>       for_no_font = false,
>       len = 4,
>       ch = 0
>     },
>     val = 32
>   }
> }
> 
> 
> Thanks.

Thanks, but this seems to be from a different GDB session?  The vpos is 24 instead of 29  and the data of the glyph structure clearly differs from what pgrowx displayed in your previous report?  I need consistent and coherent data from the same crash.

Or maybe you can come up with a reproduction recipe ?  That'd really make the debugging much more efficient...

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.