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

[Eli Zaretskii]

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

> The crash happened when doing a page-down while viewing the
> message archived at
> <http://lists.gnu.org/archive/html/emacs-devel/2012-01/msg00824.html>

FWIW, I read that message without any problems in Rmail, neither with
the current trunk nor with the 24.0.92 pretest.  But that's a 32-bit
build on Windows, while yours is a 64-bit build on GNU/Linux.

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

I have an idea for how to make the display more reasonable in this
(quite frequent) use case, but it will have to wait until after the
release of Emacs 24.1, because it could have wide potentially
surprising effects which will need to be carefully considered.

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

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

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

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

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

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

Thanks.