bug#17169: fails to start with (setq force-load-messages t) in ~/.emacs

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Thu, 03 Apr 2014 06:35:09 +0000
> 
>  >> What bothers me the most here is how force-load-messages interferes
>  >> with an otherwise working build?
> 
>  > That part is quite clear: it requires one more slot in the
>  > staticvec[] array.

This was wrong: as you show, the problem is infinite recursion in
calling bidi_initialize.

>  > Can you run Emacs under GDB, put a breakpoint in staticpro, and when
>  > it breaks, show the backtrace and the value of staticidx?
> 
>       Sure, MIMEd.
> 
>       The first time the breakpoint fires, staticidx is 1417.  I then
>       set the breakpoint condition to “staticidx > 2040”, and get one
>       another backtrace, this one suggesting that bidi_initialize ()
>       was called recursively:

Boy, am I glad that I asked.  Because now I see some snafu here;
there's nothing wrong with size of the staticvec[] array.

> #1  0x00000000004760b9 in bidi_initialize () at ../../src/bidi.c:770
> …
> #21 0x00000000004760d0 in bidi_initialize () at ../../src/bidi.c:772
> …
> #41 0x00000000004760d0 in bidi_initialize () at ../../src/bidi.c:772
> …
> #61 0x00000000004760d0 in bidi_initialize () at ../../src/bidi.c:772
> #62 0x0000000000478f97 in bidi_init_it (charpos=charpos@entry=0, bytepos=0, 
> #63 0x0000000000425f55 in reseat_to_string (multibyte=<optimized out>, 
> #64                       display_string (string=string@entry=0x57475c "", 

This is a symptom of a serious problem, but I don't know yet what is
the root cause here.

> Breakpoint 1, staticpro (
>     varaddress=varaddress@entry=0xa7d398 <bidi_type_table>)
>     at ../../src/alloc.c:5297
> 5297    if (staticidx >= NSTATICS)
> (gdb) bt 
> #0  staticpro (varaddress=varaddress@entry=0xa7d398 <bidi_type_table>)
>     at ../../src/alloc.c:5297
> #1  0x00000000004760b9 in bidi_initialize () at ../../src/bidi.c:770
> #2  0x0000000000478f97 in bidi_init_it (charpos=charpos@entry=0, bytepos=0, 
>     frame_window_p=frame_window_p@entry=false, 
>     bidi_it=bidi_it@entry=0x7fffffffbcd8) at ../../src/bidi.c:813
> #3  0x0000000000425f55 in reseat_to_string (multibyte=<optimized out>, 
>     field_width=<optimized out>, precision=<optimized out>, charpos=0, 
>     string=140737488338136, s=<optimized out>, it=0x7fffffffb340)
>     at ../../src/xdisp.c:6587
> #4  display_string (string=string@entry=0x57475c "", 
>     lisp_string=lisp_string@entry=11491442, 
>     face_string=face_string@entry=14993985, 
>     face_string_pos=face_string_pos@entry=1, start=start@entry=0, 
>     it=it@entry=0x7fffffffb340, field_width=<optimized out>, 
>     precision=<optimized out>, precision@entry=0, max_x=<optimized out>, 
>     max_x@entry=0, multibyte=<optimized out>) at ../../src/xdisp.c:22967
> #5  0x0000000000426935 in display_mode_element (it=it@entry=0x7fffffffb340, 
>     depth=<optimized out>, depth@entry=1, field_width=<optimized out>, 
>     precision=<optimized out>, precision@entry=0, elt=14993985, 
>     props=<optimized out>, props@entry=11491442, risky=risky@entry=0)
>     at ../../src/xdisp.c:21734
> #6  0x0000000000427dd9 in display_mode_element (it=it@entry=0x7fffffffb340, 
>     depth=1, depth@entry=0, field_width=field_width@entry=0, 
>     precision=precision@entry=0, elt=<optimized out>, elt@entry=14940422, 
>     props=11491442, risky=risky@entry=0) at ../../src/xdisp.c:21906
> #7  0x0000000000428771 in display_mode_line (w=w@entry=0xb09420, 
>     face_id=MODE_LINE_FACE_ID, format=14940422) at ../../src/xdisp.c:21423
> #8  0x0000000000428a18 in display_mode_lines (w=w@entry=0xb09420)
>     at ../../src/xdisp.c:21366
> #9  0x0000000000428bed in redisplay_mode_lines (window=11572261, 
>     force=force@entry=false) at ../../src/xdisp.c:21324
> #10 0x000000000043342b in echo_area_display (
>     update_frame_p=update_frame_p@entry=1) at ../../src/xdisp.c:11107
> #11 0x000000000043355e in message3_nolog (m=m@entry=13797553)
>     at ../../src/xdisp.c:10093
> #12 0x000000000043370b in message3 (m=13797553) at ../../src/xdisp.c:10035
> #13 0x0000000000433c40 in message_with_string (
>     m=m@entry=0x5720e4 "Loading %s...", string=8851465, log=1)
>     at ../../src/xdisp.c:10180
> #14 0x000000000051d54a in Fload (file=8851465, 
> noerror=noerror@entry=11491442, 
>     nomessage=nomessage@entry=11491490, nosuffix=nosuffix@entry=11491442, 
>     must_suffix=<optimized out>, must_suffix@entry=11491490)
>     at ../../src/lread.c:1351
> #15 0x00000000004fcfb0 in Fautoload_do_load (fundef=8851582, 
>     funname=funname@entry=16238434, macro_only=11491442)
>     at ../../src/eval.c:1970

This far things are fine, although I'd like to know what kind of
autoload caused Emacs to load some Lisp file here, and what was that
file (the value of 'file' in frame 14 or of 'string' in frame 13
should tell you that).  You'd need to "source .gdbinit" to be able to
display Lisp strings with "xstring".

> #79 0x000000000051d5f9 in Fload (file=14735265, 
>     noerror=noerror@entry=11491490, nomessage=nomessage@entry=11491490, 
>     nosuffix=nosuffix@entry=11491490, must_suffix=<optimized out>, 
>     must_suffix@entry=11491490) at ../../src/lread.c:1305
> #80 0x0000000000475bb5 in uniprop_table (prop=<optimized out>)
>     at ../../src/chartab.c:1340
> #81 0x00000000004760d0 in bidi_initialize () at ../../src/bidi.c:772
> #82 0x0000000000478f97 in bidi_init_it (charpos=charpos@entry=1, bytepos=1, 
>     frame_window_p=frame_window_p@entry=false, 
>     bidi_it=bidi_it@entry=0x7fffffffdb58) at ../../src/bidi.c:813
> #83 0x00000000004219a8 in init_iterator (it=0x7fffffffd1c0, w=0xb095c8, 
>     charpos=1, bytepos=<optimized out>, row=<optimized out>, 
>     base_face_id=DEFAULT_FACE_ID) at ../../src/xdisp.c:3017
> #84 0x000000000042eaa0 in resize_mini_window (w=0xb095c8, exact_p=1)
>     at ../../src/xdisp.c:10734
> #85 0x000000000041a244 in with_echo_area_buffer (w=0xb095c8, 
>     which=<optimized out>, fn=0x42ee70 <resize_mini_window_1>, a1=11572680, 
>     a2=11491490) at ../../src/xdisp.c:10418
> #86 0x0000000000433cfa in resize_echo_area_exactly ()
>     at ../../src/xdisp.c:10654

This part I don't understand.  It says that bidi_initialize called
uniprop_table, as it should, but then uniprop_table called Fload to
load the file uni-bidi.el.  This last part should not happen, because
uni-bidi.el is preloaded when Emacs is dumped, by virtue of this part
in characters.el (which is loaded by temacs during the build):

  ;; If bootstrapping without generated uni-*.el files, table not defined.
  (let ((table (unicode-property-table-internal 'bidi-class)))
    (when table
      (map-char-table (lambda (key val)
                        (cond
                         ((memq val '(R AL RLO RLE))
                          (modify-category-entry key ?R))
                         ((memq val '(L LRE LRO))
                          (modify-category-entry key ?L))))
                      table)))

This calls unicode-property-table-internal, which should load
uni-bidi.el.  This code runs at "temacs -l loadup dump" time, so the
result is that uni-bidi.el gets loaded and dumped into the Emacs
binary.  Therefore, the call to uniprop_table from bidi_initialize
should have found that the table is already loaded, and refrain from
trying to load it.

(The rest is clear: once uniprop_table tries to load uni-bidi.el, it
announces the fact that it loads that file, because that's the effect
of a non-nil value of force-load-messages, but displaying a message
again requires the initialization of the bidi iterator, so we again
re-enter bidi_initialize, which again calls uniprop_table, etc.)

Can you figure out how come uni-bidi.el is not preloaded in your
Emacs?  Is something wrong with your characters.el, for example?  Or
maybe the uni-*.el files are missing, in particular uni-bidi.el?

Thanks.