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

From: Nix <[email-masked]>
Date: Mon, 30 Jan 2012 18:14:28 +0000

On 27 Jan 2012, Eli Zaretskii spake thusly:

>> From: Nix <[email-masked]>
>> 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
:) emacs is too reliable, that's the problem: if it kept crashing all
the time I'd not make this sort of assumption, but since this is my
first crash in months I assumed that most of it was bug-free!

>> (but you can't see the bidi goodness there, if it *is* meant to be good
>> to find the periods transposed to the other end of the line while the
>> lines themselves still read in L2R, but right-justified. Weird, but
>> maybe intended, I dunno.)
>
> This weird display is mandated by the Unicode Bidirectional Algorithm,
> because the quoted part of the message is treated as a single
> right-to-left paragraph.  It is a single paragraph because there are
> no empty lines in it, and it takes a right-to-left paragraph direction
> because the first strong directional character is an Arabic letter,
> whose directionality is right to left.

It's not a bug then, good :)

>> 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.

Looking at variable values from optimized builds still sucks giant
asteroids through micropipettes though. :( so the parameters in the
backtraces might sometimes be lying or outdated.

>> I still have the coredump: any debugging I can do, just ask.
>
> 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
}
(gdb) print it->sp
$5 = 0
(gdb) print it->string
$6 = 12065314

Frame 8:

(gdb) print it->current
$7 = {
  pos = {
    charpos = 1430,
    bytepos = 1394
  },
  overlay_string_index = -1,
  string_pos = {
    charpos = -1,
    bytepos = -1
  },
  dpvec_index = -1
}
(gdb) print it->position
$8 = {
  charpos = 1430,
  bytepos = 1394
}
(gdb) print it->sp
$9 = 0
(gdb) print it->string
$10 = 12065314

(i.e. unchanged)

>                                Also, what do you have in the buffer
> at the position(s) shown by it->current and it->position (the
> functions in etc/emacs-buffer.gdb might come in handy for finding this
> out).

I'm afraid optimized-build hell has kicked in here:

There is no member named data.

I suspect this will be undiagnosable unless I can reproduce this in an
unoptimized build :(

>> (However, the thing was compiled with optimization, so debugging is
>> visibly degraded. I'm just about to upgrade GDB to 7.4: maybe that
>> will help a bit.)
>> 
>> No recipe from emacs -Q yet (a bit hard given that this is provoked by
>> Gnus-plus-nnml). Tomorrow I'll try to come up with a reproduction recipe
>> based on the text of the message alone.
>
> A newer GDB will help, but please also try this in an unoptimized
> build.  If you can reproduce it there, we will have much better
> chances of finding the culprit.

I'll try that soon. I doubt we can get much further with this as it
stands :(

> Also, please show the results of "xbacktrace" (starting GDB from the
> Emacs src directory should cause that be done automagically).

"There is no member named data" again. Sigh :(

>> In GNU Emacs 24.0.92.2 (x86_64-unknown-linux-gnu, X toolkit, Xaw3d scroll bars)
>>  of 2012-01-26 on spindle
>> Windowing system distributor `The X.Org Foundation', version 11.0.11003901
>> configured using `configure  '--without-pop' '--without-kerberos' '--without-hesiod' '--without-mmdf' '--with-x-toolkit=lucid' '--with-wide-int' 'NO_FAST_MATH=t''
>
> Can you tell whether you built with libraries mentioned in INSTALL
> under "Complex Text Layout support libraries", and if so, which
> versions thereof?

I didn't build with any of the complex text layout support libraries at
all.

> Also, do you have any problems whatsoever displaying etc/HELLO in its
> entirety?

No.

-- 
NULL && (void)