GNU bug report logs - #9963
./temacs -Q -nw abort in bidi_initialize

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 9963 in the body.
You can then email your comments to 9963 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Dan Nicolaescu <dann <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: ./temacs -Q -nw abort in bidi_initialize
Date: Sat, 05 Nov 2011 23:40:55 -0400

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

Message #8 received at 9963 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dan Nicolaescu <dann <at> gnu.org>
Cc: 9963 <at> debbugs.gnu.org
Subject: Re: bug#9963: ./temacs -Q -nw abort in bidi_initialize
Date: Sun, 06 Nov 2011 06:01:05 +0200

> From: Dan Nicolaescu <dann <at> 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.

Message #11 received at 9963 <at> debbugs.gnu.org (full text, mbox):

From: Dan Nicolaescu <dann <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9963 <at> debbugs.gnu.org
Subject: Re: bug#9963: ./temacs -Q -nw abort in bidi_initialize
Date: Sun, 06 Nov 2011 00:48:02 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Dan Nicolaescu <dann <at> 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?

Message #14 received at 9963 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dan Nicolaescu <dann <at> gnu.org>
Cc: 9963 <at> debbugs.gnu.org
Subject: Re: bug#9963: ./temacs -Q -nw abort in bidi_initialize
Date: Sun, 06 Nov 2011 02:24:43 -0500

> From: Dan Nicolaescu <dann <at> gnu.org>
> Cc: 9963 <at> debbugs.gnu.org
> Date: Sun, 06 Nov 2011 00:48:02 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Dan Nicolaescu <dann <at> 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.

Message #17 received at 9963 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Dan Nicolaescu <dann <at> gnu.org>, 9963 <at> debbugs.gnu.org
Subject: Re: bug#9963: ./temacs -Q -nw abort in bidi_initialize
Date: Sun, 06 Nov 2011 10:47:13 +0100

Eli Zaretskii <eliz <at> 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 <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #20 received at 9963 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: dann <at> gnu.org, 9963 <at> debbugs.gnu.org
Subject: Re: bug#9963: ./temacs -Q -nw abort in bidi_initialize
Date: Sun, 06 Nov 2011 05:08:46 -0500

> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: Dan Nicolaescu <dann <at> gnu.org>,  9963 <at> debbugs.gnu.org
> Date: Sun, 06 Nov 2011 10:47:13 +0100
> 
> Eli Zaretskii <eliz <at> 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.

Message #23 received at 9963 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: dann <at> gnu.org
Cc: 9963 <at> debbugs.gnu.org
Subject: Re: bug#9963: ./temacs -Q -nw abort in bidi_initialize
Date: Sun, 06 Nov 2011 20:28:53 +0200

> Date: Sun, 06 Nov 2011 02:24:43 -0500
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 9963 <at> 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.

Message #28 received at 9963-done <at> debbugs.gnu.org (full text, mbox):

From: Dan Nicolaescu <dann <at> gnu.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 9963-done <at> debbugs.gnu.org
Subject: Re: bug#9963: ./temacs -Q -nw abort in bidi_initialize
Date: Sun, 06 Nov 2011 18:10:23 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Sun, 06 Nov 2011 02:24:43 -0500
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: 9963 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.