bug#9963: ./temacs -Q -nw abort in bidi_initialize

bug#9963: ./temacs -Q -nw abort in bidi_initialize

[Dan Nicolaescu]

./temacs -Q -nw 
aborts in bidi_initialize

It used to work a few months ago.

Program received signal SIGABRT, Aborted.
0x0000003c994355b7 in kill () from /lib64/libc.so.6
Missing separate debuginfos, use: debuginfo-install glibc-2.14-5.x86_64 ncurses-libs-5.8-2.20110319.fc15.x86_64
(gdb) bt
#0  0x0000003c994355b7 in kill () from /lib64/libc.so.6
#1  0x00000000004bd1d6 in abort () at /tmp/trunk/src/emacs.c:386
#2  0x00000000004a5344 in bidi_initialize () at /tmp/trunk/src/bidi.c:758
#3  0x00000000004a54c5 in bidi_init_it (charpos=0x0, bytepos=0x0, frame_window_p=0x0, bidi_it=0x7fffffffd308)
    at /tmp/trunk/src/bidi.c:802
#4  0x0000000000425624 in reseat_to_string (it=0x7fffffffc960, s=0xb6dc00 '-' <repeats 200 times>..., string=0xb53a12, 
    charpos=0x0, precision=0x0, field_width=0x0, multibyte=0x0)
    at /tmp/trunk/src/xdisp.c:6190
#5  0x0000000000448981 in display_string (string=0xb6dc00 '-' <repeats 200 times>..., lisp_string=0xb53a12, 
    face_string=0x825d01, face_string_pos=0x1, start=0x0, it=0x7fffffffc960, field_width=0x0, precision=0x0, max_x=0x0, 
    multibyte=0x0) at /tmp/trunk/src/xdisp.c:21330
#6  0x000000000044569c in display_mode_element (it=0x7fffffffc960, depth=0x1, field_width=0x0, precision=0x0, elt=0x825d01, 
    props=0xb53a12, risky=0x0) at /tmp/trunk/src/xdisp.c:20102
#7  0x0000000000444ab8 in display_mode_line (w=0xb696d0, face_id=MODE_LINE_FACE_ID, format=0x825d01)
    at /tmp/trunk/src/xdisp.c:19791
#8  0x000000000044481e in display_mode_lines (w=0xb696d0)
    at /tmp/trunk/src/xdisp.c:19733
#9  0x00000000004445f1 in redisplay_mode_lines (window=0xb696d5, force=0x0)
    at /tmp/trunk/src/xdisp.c:19692
#10 0x0000000000430e32 in echo_area_display (update_frame_p=0x1)
    at /tmp/trunk/src/xdisp.c:10534
#11 0x000000000042e91d in message3_nolog (m=0xb69001, nbytes=0x1d, multibyte=0x0)
    at /tmp/trunk/src/xdisp.c:9436
#12 0x000000000042e62e in message3 (m=0xb69001, nbytes=0x1d, multibyte=0x0)
    at /tmp/trunk/src/xdisp.c:9373
#13 0x000000000042ec3e in message_with_string (m=0x5fab95 "Loading %s (source)...", string=0xba5371, log=0x1)
    at /tmp/trunk/src/xdisp.c:9517
#14 0x0000000000587013 in Fload (file=0xba5371, noerror=0xb53a12, nomessage=0xb53a12, nosuffix=0xb53a12, must_suffix=0xb53a12)
    at /tmp/trunk/src/lread.c:1295
#15 0x000000000055c865 in eval_sub (form=0xb75426) at /tmp/trunk/src/eval.c:2336
#16 0x000000000055c0e8 in Feval (form=0xb75426, lexical=0xb53a12)
    at /tmp/trunk/src/eval.c:2176
#17 0x00000000004c1462 in top_level_2 () at /tmp/trunk/src/keyboard.c:1167
#18 0x000000000055aac4 in internal_condition_case (bfun=0x4c1445 <top_level_2>, handlers=0xb604e2, hfun=0x4c1030 <cmd_error>)
    at /tmp/trunk/src/eval.c:1499
#19 0x00000000004c149c in top_level_1 (ignore=0xb53a12)
    at /tmp/trunk/src/keyboard.c:1175
#20 0x000000000055a44e in internal_catch (tag=0xb5f442, func=0x4c1464 <top_level_1>, arg=0xb53a12)
    at /tmp/trunk/src/eval.c:1256
#21 0x00000000004c13c0 in command_loop () at /tmp/trunk/src/keyboard.c:1130
#22 0x00000000004c0b74 in recursive_edit_1 () at /tmp/trunk/src/keyboard.c:757
#23 0x00000000004c0d17 in Frecursive_edit () at /tmp/trunk/src/keyboard.c:821
#24 0x00000000004bede6 in main (argc=0x3, argv=0x7fffffffe4c8)
    at /tmp/trunk/src/emacs.c:1707

Lisp Backtrace:
"load" (0xffffdb90)
(gdb) 

bug#9963: ./temacs -Q -nw abort in bidi_initialize

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@gnu.org>
> Date: Sat, 05 Nov 2011 23:40:55 -0400
> 
> ./temacs -Q -nw 
> aborts in bidi_initialize
> 
> It used to work a few months ago.

Yes, but the way bidi properties of characters are accessed has
changed since then.

This abort means you somehow have a problem loading uni-bidi.el, or
didn't load it at all, or perhaps load a wrong uni-bidi.el (e.g., from
Emacs 23).  It is strange that it works without -nw, though.

bug#9963: ./temacs -Q -nw abort in bidi_initialize

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dan Nicolaescu <dann@gnu.org>
>> Date: Sat, 05 Nov 2011 23:40:55 -0400
>> 
>> ./temacs -Q -nw 
>> aborts in bidi_initialize
>> 
>> It used to work a few months ago.
>
> Yes, but the way bidi properties of characters are accessed has
> changed since then.
>
> This abort means you somehow have a problem loading uni-bidi.el, or
> didn't load it at all, or perhaps load a wrong uni-bidi.el (e.g., from
> Emacs 23).  It is strange that it works without -nw, though.

It looks this happens when printing the first "Loading" message at
startup to load loadup.el.  Is uni-bidi.el loaded before that?

bug#9963: ./temacs -Q -nw abort in bidi_initialize

[Eli Zaretskii]

> From: Dan Nicolaescu <dann@gnu.org>
> Cc: 9963@debbugs.gnu.org
> Date: Sun, 06 Nov 2011 00:48:02 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Dan Nicolaescu <dann@gnu.org>
> >> Date: Sat, 05 Nov 2011 23:40:55 -0400
> >> 
> >> ./temacs -Q -nw 
> >> aborts in bidi_initialize
> >> 
> >> It used to work a few months ago.
> >
> > Yes, but the way bidi properties of characters are accessed has
> > changed since then.
> >
> > This abort means you somehow have a problem loading uni-bidi.el, or
> > didn't load it at all, or perhaps load a wrong uni-bidi.el (e.g., from
> > Emacs 23).  It is strange that it works without -nw, though.
> 
> It looks this happens when printing the first "Loading" message at
> startup to load loadup.el.

That figures: Emacs needs uni-bidi for display, and `message' enters
redisplay.

>  Is uni-bidi.el loaded before that?

Evidently, it isn't.  I think it is pulled in when charprop is loaded,
but that's half-way down loadup.el.

We need to find a way of loading uni-bidi and uni-mirrored before
loading loadup.el.  I will get to that later today, if no one beats me
to it.

And I still wonder how come this works in a GUI session.

bug#9963: ./temacs -Q -nw abort in bidi_initialize

[Andreas Schwab]

Eli Zaretskii <eliz@gnu.org> writes:

> And I still wonder how come this works in a GUI session.

That doesn't create a real frame until after loadup is loaded.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#9963: ./temacs -Q -nw abort in bidi_initialize

[Eli Zaretskii]

> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Dan Nicolaescu <dann@gnu.org>,  9963@debbugs.gnu.org
> Date: Sun, 06 Nov 2011 10:47:13 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > And I still wonder how come this works in a GUI session.
> 
> That doesn't create a real frame until after loadup is loaded.

Thanks, this unlocks what was a mystery in my eyes.

bug#9963: ./temacs -Q -nw abort in bidi_initialize

[Eli Zaretskii]

> Date: Sun, 06 Nov 2011 02:24:43 -0500
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 9963@debbugs.gnu.org
> 
> > > This abort means you somehow have a problem loading uni-bidi.el, or
> > > didn't load it at all, or perhaps load a wrong uni-bidi.el (e.g., from
> > > Emacs 23).  It is strange that it works without -nw, though.
> > 
> > It looks this happens when printing the first "Loading" message at
> > startup to load loadup.el.
> 
> That figures: Emacs needs uni-bidi for display, and `message' enters
> redisplay.
> 
> >  Is uni-bidi.el loaded before that?
> 
> Evidently, it isn't.  I think it is pulled in when charprop is loaded,
> but that's half-way down loadup.el.
> 
> We need to find a way of loading uni-bidi and uni-mirrored before
> loading loadup.el.  I will get to that later today, if no one beats me
> to it.

I think I fixed this (revision 106305 on the trunk), please check.

For the record: I decided that loading uni-bidi in advance is not a
good idea, as proper functioning of character property tables needed
by bidi.c depends on many other *.el files that are normally loaded
before uni-bidi.  There be dragons there.  So instead, I disabled bidi
reordering for as long as purify-flag is non-nil; I hope this is TRT
for all supported configurations, including CANNOT_DUMP.

bug#9963: ./temacs -Q -nw abort in bidi_initialize

[Dan Nicolaescu]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sun, 06 Nov 2011 02:24:43 -0500
>> From: Eli Zaretskii <eliz@gnu.org>
>> Cc: 9963@debbugs.gnu.org
>> 
>> > > This abort means you somehow have a problem loading uni-bidi.el, or
>> > > didn't load it at all, or perhaps load a wrong uni-bidi.el (e.g., from
>> > > Emacs 23).  It is strange that it works without -nw, though.
>> > 
>> > It looks this happens when printing the first "Loading" message at
>> > startup to load loadup.el.
>> 
>> That figures: Emacs needs uni-bidi for display, and `message' enters
>> redisplay.
>> 
>> >  Is uni-bidi.el loaded before that?
>> 
>> Evidently, it isn't.  I think it is pulled in when charprop is loaded,
>> but that's half-way down loadup.el.
>> 
>> We need to find a way of loading uni-bidi and uni-mirrored before
>> loading loadup.el.  I will get to that later today, if no one beats me
>> to it.
>
> I think I fixed this (revision 106305 on the trunk), please check.


Thanks for the quick fix, it looks like everything works fine.


> For the record: I decided that loading uni-bidi in advance is not a
> good idea, as proper functioning of character property tables needed
> by bidi.c depends on many other *.el files that are normally loaded
> before uni-bidi.  There be dragons there.  So instead, I disabled bidi
> reordering for as long as purify-flag is non-nil; I hope this is TRT
> for all supported configurations, including CANNOT_DUMP.

Agreed.