bug#39207: WITH dgb symbols Re: bug#39207: 28.0.50; crash when sending gnus message

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 22 Jan 2020 13:12:54 +0100
> Cc: 39207@debbugs.gnu.org
> 
> Eli, the abort in Gijs' backtrace is coming from
> 
>   if (ch < 0 || ch > MAX_CHAR)
>     emacs_abort ();
> 
> in bidi.c

I need to see the value of 'ch' in this case.  It's "optimized out" (a
euphemism for "GDB is confused") in Gijs' backtrace, but if one goes up
the call-stack, one should be able to see it in, say, frame #4:

>     Gijs> #4  0x0000555555635547 in bidi_resolve_explicit (bidi_it=0x7fffffff7750) at bidi.c:2019

as bidi_it->ch.

Also...

>     Gijs> #35 0x00005555556f8100 in call_debugger (arg=0x555558687fa3) at eval.c:339
>     Gijs> #36 0x00005555556f8713 in maybe_call_debugger (data=0x555558688013, sig=0xe9d0, conditions=0x7ffff1be007b) at lisp.h:1032
>     Gijs> #37 signal_or_quit (error_symbol=0xe9d0, data=0x555558688013, keyboard_quit=<optimized out>) at eval.c:1666
>     Gijs> #38 0x000055555559a5f0 in Fsignal (error_symbol=<optimized out>, error_symbol@entry=0xe9d0, data=<optimized out>) at eval.c:1568
>     Gijs> #39 0x000055555559a7ca in xsignal (data=<optimized out>, error_symbol=0xe9d0) at lisp.h:4140
>     Gijs> #40 xsignal2 (error_symbol=error_symbol@entry=0xe9d0, arg1=arg1@entry=0xc8a0, arg2=arg2@entry=0x14a) at eval.c:1713
>     Gijs> #41 0x00005555555997f9 in wrong_type_argument (predicate=predicate@entry=0xc8a0, value=value@entry=0x14a) at lisp.h:1032
>     Gijs> #42 0x0000555555599e07 in CHECK_TYPE (x=0x14a, predicate=0xc8a0, ok=0) at data.c:1991
>     Gijs> #43 CHECK_SYMBOL (x=0x14a) at lisp.h:1052
>     Gijs> #44 set_internal (symbol=0x14a, newval=<optimized out>, where=<optimized out>, bindflag=<optimized out>) at data.c:1307
>     Gijs> #45 0x00005555556e70c6 in Fset (symbol=<optimized out>, newval=0x9c4e) at lisp.h:1032

see frame #41? there's a Lisp error here, triggered by calling Fset
from Lisp.  In frame #40, we could see the error symbol (most probably
wrong-type-argument) and error data, which is much more interesting.

> 18068     /* Some sanity checks.  */
> 18069     CHECK_WINDOW_END (w);
> 18070     if (Z == Z_BYTE && CHARPOS (opoint) != BYTEPOS (opoint))
> 18071       emacs_abort ();
> 18072     if (BYTEPOS (opoint) < CHARPOS (opoint))
> 18073       emacs_abort ();
> 18074
> 18075     if (mode_line_update_needed (w))
> (gdb) p Z
> $1 = 2804
> (gdb) p Z_BYTE
> $2 = 2804
> (gdb) p CHARPOS(opoint)
> $3 = 495
> (gdb) p BYTEPOS(opoint)
> $4 = 497

This indeed cannot happen, since $1 and $2 mean the buffer is either
unibyte or pure-ASCII (the character count and the byte count are
identical), whereas $3 and $4 tell us there's some multibyte character
in the buffer before or at buffer position 495.

Is the buffer multibyte or not?  (You can tell by looking at the value
of 'BVAR (buffer, enable_multibyte_characters)'.)  Also, can you show
the entire text of the buffer, which begins at current_buffer->text->beg?
You need to exercise caution near the gap (unless it's at the end of
the buffer), because the gap is not part of buffer text.

Thanks.