bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#44506: 28.0.50; Segfault on opening a particular message in Gnus in


From: Eli Zaretskii
Subject: bug#44506: 28.0.50; Segfault on opening a particular message in Gnus in terminal/tty
Date: Sat, 07 Nov 2020 22:29:42 +0200

> From: Amin Bandali <bandali@gnu.org>
> Cc: 44506@debbugs.gnu.org, Eric Abrahamsen <eric@ericabrahamsen.net>
> Date: Sat, 07 Nov 2020 15:03:53 -0500
> 
> After some bisecting of my config files, I narrowed the segaulting of
> Gnus when opening that message down to inclusion of (require 'ebdb-gnus)
> in my configs.  ebdb-gnus is part of EBDB, available on GNU ELPA.  I'm
> Cc'ing Eric, EBDB's creator and maintainer, in case he might have any
> ideas.

I don't see anything in EBDB that could cause Emacs to use static
compositions, but maybe I'm missing something.

> >       if (src->u.cmp.automatic)
> >         {
> >           gstring = composition_gstring_from_id (src->u.cmp.id);
> >           required = src->slice.cmp.to - src->slice.cmp.from + 1;
> >         }
> >       else
> >         {
> >           cmp = composition_table[src->u.cmp.id];  <<<<<<<<<<<<<<<
> >           required = cmp->glyph_len;
> >         }
> >
> > If that is true, then I don't understand how it happened: we don't use
> > any compositions except automatic in Emacs, so I'm unsure how you get
> > to that place.  Can you see which place in the code indeed crashes and
> > why?
> 
> GDB's source display does indeed highlight that line for me.  Is this
> the confirmation you were looking for, or did you mean I should look
> into disabling optimization and *then* run Emacs through GDB to collect
> the backtrace?

Reproducing in an unoptimized build would be the most efficient way of
telling if that's indeed something related to static compositions.

Thanks.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]