bug#9671: 24.0.50; Two bidi crashes

[Eli Zaretskii]

> From: David Reitter <david.reitter@gmail.com>
> Date: Wed, 5 Oct 2011 16:49:47 -0400
> Cc: 9671@debbugs.gnu.org
> 
> First of all, this may have to do with GDB and passing Emacs environment 
> variables to another Emacs instance.

But the original reports did not say Emacs was started from GDB that
itself was started from another Emacs instance.  Did I miss something?

> This may explain why we're seeing this abort in bidi:
> 
> I am reproducing at least some type of crash in bidi_initialize() when I 
> debug Emacs (24) from gdb session inside an Emacs 23 - this occurs all the 
> time, but not when I start it outside of Emacs/GDB:

I know about this issue, but I thought it only happens on MS-Windows,
because the Windows build pushes values of EMACSDATA and EMACSLOADPATH
into its own environment, and those values correspond to the version
of Emacs that runs.  Does Emacs on Apple systems also do that?

Anyway, use the GDB command "unset environment" to remove these
variables from the environment of Emacs being debugged.  Do that
_before_ you type the "run" command in GDB.

> The abort in question happens here:
> 
>   bidi_mirror_table = uniprop_table (intern ("mirroring"));
>   if (NILP (bidi_mirror_table))
>     abort ();
> 
> uniprop_table returns Qnil in this situation (chartab.c:1340):

Yes, because Emacs 23 didn't have the "mirroring" table in
uni-mirrored.el.

> EMACSDATA=/Users/dr/ae.git/nextstep/Aquamacs.app/Contents/Resources/etc
> EMACSPATH=/Users/dr/ae.git/nextstep/Aquamacs.app/Contents/MacOS/bin
> EMACS=t
> EMACSLOADPATH=/Users/dr/ae.git/nextstep/Aquamacs.app/Contents/Resources/lisp:/Users/dr/ae.git/nextstep/Aquamacs.app/Contents/Resources/leim
> INSIDE_EMACS=23.3.50.39,comint
> EMACSDOC=/Users/dr/ae.git/nextstep/Aquamacs.app/Contents/Resources/etc
> 
> Does this explain what's going on?

It does, but how is this related to the original report?  There was no
GDB there nor another instance of Emacs, at least they were not
mentioned.  That's why I said I can only understand the original
report if Emacs was badly deployed.

And the other crash was entirely unrelated to this issue anyway.