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

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

bug#10617: 24.0.92; Bidi crash reading a message from emacs-devel


From: Eli Zaretskii
Subject: bug#10617: 24.0.92; Bidi crash reading a message from emacs-devel
Date: Mon, 30 Jan 2012 21:03:38 +0200

> From: Nix <nix@esperi.org.uk>
> Cc: 10617@debbugs.gnu.org
> Emacs: is that a Lisp interpreter in your editor, or are you just happy to 
> see me?
> Date: Mon, 30 Jan 2012 18:14:28 +0000
> 
> On 27 Jan 2012, Eli Zaretskii spake thusly:
> 
> >> From: Nix <nix@esperi.org.uk>
> >> Emacs: no job too big... no job.
> >> Date: Thu, 26 Jan 2012 22:40:22 +0000
> >> 
> >> I just got a bidi crash reading an emacs-devel message in Gnus (bzr
> >> r106941).
> >
> > I'm curious: why do you think this crash has anything to do with bidi?
> > There are no bidi-related functions anywhere in the backtrace you
> > show.
> 
> Oh. Maybe I jumped to conclusions, but the fact that I got it when
> viewing a heavily-bidi message roused suspicions too strong to see past

Arabic text is special in that it uses character compositions, not
only bidi display.  And the crash is inside code that handles
character compositions.

> >> It is quite clear from the backtrace that the second parameter to
> >> char_table_ref() has been garbaged, apparently being set to 2^32/1000
> >> (again, passing strange).
> >
> > Sorry, I don't believe backtraces from optimized builds, they lie
> > through their teeth.
> 
> Backtraces from optimized GCC builds on x86_64 Linux (and, on modern
> GCC's, on i386 too) don't work by doing frame pointer walking anymore,
> they do DWARF walking. If that lies, the stack is severely corrupted and
> exception handling will also crash: perhaps not terribly relevant for
> most C programs but still a sign that keeping this particular data
> structure un-fudged-up is considered important. (There are the usual
> modifications due to inlining and sibcalls but they are easy to
> compensate for.)
> 
> So it's a good bit more reliable than it used to be. You can generally
> rely on the function names being valid.

The problem is that (a) static functions inlined by the compiler don't
always appear in the backtraces, and (b) too many arguments in the
calls are not shown ("optimized out") or shown with incorrect values.

> > It would be interesting to see it->current, it->position, it->sp, and
> > it->string in frames #6 and #8.
> 
> Frame 6:
> 
> (gdb) print it->current
> $3 = {
>   pos = {
>     charpos = 1430,
>     bytepos = 1394
>   },
>   overlay_string_index = -1,
>   string_pos = {
>     charpos = -1,
>     bytepos = -1
>   },
>   dpvec_index = -1
> }
> (gdb) print it->position
> $4 = {
>   charpos = 1430,
>   bytepos = 1394
> }

If bytepos is smaller than charpos, it generally means trouble...

> (gdb) print it->sp
> $5 = 0
> (gdb) print it->string
> $6 = 12065314

What does "xtype" say about this string?  If it says Lisp_String, what
does "xstring" say?





reply via email to

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