* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
@ 2016-03-10 5:41 Ken Raeburn
2016-03-10 7:10 ` Eli Zaretskii
0 siblings, 1 reply; 26+ messages in thread
From: Ken Raeburn @ 2016-03-10 5:41 UTC (permalink / raw)
To: 22975
I’d mentioned this before but just want to make sure it doesn’t fall off the radar…
I’d previously assumed this wasn’t an important use case at the moment, but the “nacl” configuration sets CANNOT_DUMP mode, and on any platform where address sanitization is detected, the configure script will emit a warning message recommending CANNOT_DUMP mode, so I’m not so sure.
$ ../configure --prefix=`pwd`/Inst --enable-checking CANNOT_DUMP=yes --with-x-toolkit=lucid
$ make -j6 all && make install
$ ./Inst/bin/emacs
… works okay on X11; “loading” messages are displayed on stdout before frame is created
$ ./Inst/bin/emacs -nw
Fatal error 6: Aborted
Backtrace:
./Inst/bin/emacs[0x5437a2]
./Inst/bin/emacs[0x525874]
./Inst/bin/emacs[0x543833]
[…]
(I rechecked with “-Q -nw” and got the same results.)
GDB says:
#0 terminate_due_to_signal (sig=sig@entry=6, backtrace_limit=backtrace_limit@entry=40) at ../../src/emacs.c:352
No locals.
#1 0x0000000000543833 in emacs_abort () at ../../src/sysdep.c:2247
No locals.
#2 0x00000000004d86da in bidi_initialize () at ../../src/bidi.c:1097
No locals.
#3 0x00000000004dcddf in bidi_init_it (charpos=charpos@entry=1, bytepos=1, frame_window_p=<optimized out>, bidi_it=bidi_it@entry=0x7fffffffd840) at ../../src/bidi.c:1145
No locals.
#4 0x000000000044a906 in init_iterator (it=0x7fffffffcea0, w=0xcfe5b0, charpos=1, bytepos=<optimized out>, row=<optimized out>, base_face_id=DEFAULT_FACE_ID) at ../../src/xdisp.c:2981
remapped_base_face_id = DEFAULT_FACE_ID
#5 0x00000000004609f7 in resize_mini_window (w=0xcfe5b0, exact_p=<optimized out>) at ../../src/xdisp.c:10937
total_height = 23
unit = 1
max_height = <optimized out>
old_current_buffer = 0x0
it = {
window = 13624757,
w = 0xcfe5b0,
f = 0xcfe1c0,
method = GET_FROM_BUFFER,
stop_charpos = 1,
prev_stop = 0,
base_level_stop = 0,
end_charpos = 76,
s = 0x0,
string_nchars = 0,
redisplay_end_trigger_charpos = 0,
multibyte_p = true,
header_line_p = false,
string_from_display_prop_p = false,
string_from_prefix_prop_p = false,
from_disp_prop_p = false,
ellipsis_p = false,
avoid_cursor_p = false,
dp = 0x0,
dpvec = 0x0,
dpend = 0x0,
dpvec_char_len = 0,
dpvec_face_id = 0,
saved_face_id = 0,
ctl_chars = {0 <repeats 16 times>},
start = {
pos = {
charpos = 1,
bytepos = 1
},
overlay_string_index = -1,
string_pos = {
charpos = -1,
bytepos = -1
},
dpvec_index = -1
},
current = {
pos = {
charpos = 1,
bytepos = 1
},
overlay_string_index = -1,
string_pos = {
charpos = -1,
bytepos = -1
},
dpvec_index = -1
},
n_overlay_strings = 0,
overlay_strings_charpos = 0,
overlay_strings = {0 <repeats 16 times>},
string_overlays = {0 <repeats 16 times>},
string = 0,
from_overlay = 0,
stack = {{
string = 0,
string_nchars = 0,
end_charpos = 0,
stop_charpos = 0,
prev_stop = 0,
base_level_stop = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = false,
charpos = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
face_id = 0,
u = {
image = {
object = 0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
image_id = 0
},
stretch = {
object = 0
},
xwidget = {
object = 0
}
},
position = {
charpos = 0,
bytepos = 0
},
current = {
pos = {
charpos = 0,
bytepos = 0
},
overlay_string_index = 0,
string_pos = {
charpos = 0,
bytepos = 0
},
dpvec_index = 0
},
from_overlay = 0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
paragraph_embedding = NEUTRAL_DIR,
multibyte_p = false,
string_from_display_prop_p = false,
string_from_prefix_prop_p = false,
display_ellipsis_p = false,
avoid_cursor_p = false,
bidi_p = false,
from_disp_prop_p = false,
line_wrap = TRUNCATE,
voffset = 0,
space_width = 0,
font_height = 0
}, {
string = 0,
string_nchars = 0,
end_charpos = 0,
stop_charpos = 0,
prev_stop = 0,
base_level_stop = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = false,
charpos = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
face_id = 0,
u = {
image = {
object = 0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
image_id = 0
},
stretch = {
object = 0
},
xwidget = {
object = 0
}
},
position = {
charpos = 0,
bytepos = 0
},
current = {
pos = {
charpos = 0,
bytepos = 0
},
overlay_string_index = 0,
string_pos = {
charpos = 0,
bytepos = 0
},
dpvec_index = 0
},
from_overlay = 0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
paragraph_embedding = NEUTRAL_DIR,
multibyte_p = false,
string_from_display_prop_p = false,
string_from_prefix_prop_p = false,
display_ellipsis_p = false,
avoid_cursor_p = false,
bidi_p = false,
from_disp_prop_p = false,
line_wrap = TRUNCATE,
voffset = 0,
space_width = 0,
font_height = 0
}, {
string = 0,
string_nchars = 0,
end_charpos = 0,
stop_charpos = 0,
prev_stop = 0,
base_level_stop = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = false,
charpos = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
face_id = 0,
u = {
image = {
object = 0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
image_id = 0
},
stretch = {
object = 0
},
xwidget = {
object = 0
}
},
position = {
charpos = 0,
bytepos = 0
},
current = {
pos = {
charpos = 0,
bytepos = 0
},
overlay_string_index = 0,
string_pos = {
charpos = 0,
bytepos = 0
},
dpvec_index = 0
},
from_overlay = 0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
paragraph_embedding = NEUTRAL_DIR,
multibyte_p = false,
string_from_display_prop_p = false,
string_from_prefix_prop_p = false,
display_ellipsis_p = false,
avoid_cursor_p = false,
bidi_p = false,
from_disp_prop_p = false,
line_wrap = TRUNCATE,
voffset = 0,
space_width = 0,
font_height = 0
}, {
string = 0,
string_nchars = 0,
end_charpos = 0,
stop_charpos = 0,
prev_stop = 0,
base_level_stop = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = false,
charpos = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
face_id = 0,
u = {
image = {
object = 0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
image_id = 0
},
stretch = {
object = 0
},
xwidget = {
object = 0
}
},
position = {
charpos = 0,
bytepos = 0
},
current = {
pos = {
charpos = 0,
bytepos = 0
},
overlay_string_index = 0,
string_pos = {
charpos = 0,
bytepos = 0
},
dpvec_index = 0
},
from_overlay = 0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
paragraph_embedding = NEUTRAL_DIR,
multibyte_p = false,
string_from_display_prop_p = false,
string_from_prefix_prop_p = false,
display_ellipsis_p = false,
avoid_cursor_p = false,
bidi_p = false,
from_disp_prop_p = false,
line_wrap = TRUNCATE,
voffset = 0,
space_width = 0,
font_height = 0
}, {
string = 0,
string_nchars = 0,
end_charpos = 0,
stop_charpos = 0,
prev_stop = 0,
base_level_stop = 0,
cmp_it = {
stop_pos = 0,
id = 0,
ch = 0,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = false,
charpos = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
face_id = 0,
u = {
image = {
object = 0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
image_id = 0
},
stretch = {
object = 0
},
xwidget = {
object = 0
}
},
position = {
charpos = 0,
bytepos = 0
},
current = {
pos = {
charpos = 0,
bytepos = 0
},
overlay_string_index = 0,
string_pos = {
charpos = 0,
bytepos = 0
},
dpvec_index = 0
},
from_overlay = 0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
paragraph_embedding = NEUTRAL_DIR,
multibyte_p = false,
string_from_display_prop_p = false,
string_from_prefix_prop_p = false,
display_ellipsis_p = false,
avoid_cursor_p = false,
bidi_p = false,
from_disp_prop_p = false,
line_wrap = TRUNCATE,
voffset = 0,
space_width = 0,
font_height = 0
}},
sp = 0,
selective = 0,
what = IT_CHARACTER,
face_id = 0,
selective_display_ellipsis_p = true,
ctl_arrow_p = true,
face_box_p = false,
start_of_box_run_p = false,
end_of_box_run_p = false,
overlay_strings_at_end_processed_p = false,
ignore_overlay_strings_at_pos_p = false,
glyph_not_available_p = false,
starts_in_middle_of_char_p = false,
face_before_selective_p = false,
constrain_row_ascent_descent_p = false,
line_wrap = WINDOW_WRAP,
base_face_id = 0,
c = 0,
len = 0,
cmp_it = {
stop_pos = 0,
id = -1,
ch = 0,
rule_idx = 0,
lookback = 0,
nglyphs = 0,
reversed_p = false,
charpos = 0,
nchars = 0,
nbytes = 0,
from = 0,
to = 0,
width = 0
},
char_to_display = 0,
glyphless_method = GLYPHLESS_DISPLAY_THIN_SPACE,
image_id = 0,
xwidget = 0x0,
slice = {
x = 0,
y = 0,
width = 0,
height = 0
},
space_width = 0,
voffset = 0,
tab_width = 8,
font_height = 0,
object = 0,
position = {
charpos = 0,
bytepos = 0
},
truncation_pixel_width = 0,
continuation_pixel_width = 1,
first_visible_x = 0,
last_visible_x = 79,
last_visible_y = 1,
extra_line_spacing = 0,
max_extra_line_spacing = 0,
override_ascent = -1,
override_descent = 0,
override_boff = 0,
glyph_row = 0x0,
area = TEXT_AREA,
nglyphs = 1,
pixel_width = 0,
ascent = 0,
descent = 0,
max_ascent = 0,
max_descent = 0,
phys_ascent = 0,
phys_descent = 0,
max_phys_ascent = 0,
max_phys_descent = 0,
current_x = 0,
continuation_lines_width = 0,
eol_pos = {
charpos = 0,
bytepos = 0
},
current_y = 0,
first_vpos = 0,
vpos = 0,
hpos = 0,
left_user_fringe_bitmap = 0,
right_user_fringe_bitmap = 0,
left_user_fringe_face_id = 0,
right_user_fringe_face_id = 0,
bidi_p = true,
bidi_it = {
bytepos = 0,
charpos = 0,
ch = 0,
nchars = 0,
ch_len = 0,
type = UNKNOWN_BT,
type_after_wn = UNKNOWN_BT,
orig_type = UNKNOWN_BT,
resolved_level = 0 '\000',
isolate_level = 0 '\000',
invalid_levels = 0,
invalid_isolates = 0,
prev = {
charpos = 0,
type = UNKNOWN_BT,
orig_type = UNKNOWN_BT
},
last_strong = {
charpos = 0,
type = UNKNOWN_BT,
orig_type = UNKNOWN_BT
},
next_for_neutral = {
charpos = 0,
type = UNKNOWN_BT,
orig_type = UNKNOWN_BT
},
prev_for_neutral = {
charpos = 0,
type = UNKNOWN_BT,
orig_type = UNKNOWN_BT
},
next_for_ws = {
charpos = 0,
type = UNKNOWN_BT,
orig_type = UNKNOWN_BT
},
bracket_pairing_pos = 0,
bracket_enclosed_type = UNKNOWN_BT,
next_en_pos = 0,
next_en_type = UNKNOWN_BT,
sos = NEUTRAL_DIR,
scan_dir = 0,
disp_pos = 0,
disp_prop = 0,
stack_idx = 0,
level_stack = {{
next_for_neutral_pos = 0,
next_for_neutral_type = 0,
last_strong_type = 0,
prev_for_neutral_type = 0,
level = 0 '\000',
flags = 0 '\000'
} <repeats 128 times>},
string = {
lstring = 0,
s = 0x0,
schars = 0,
bufpos = 0,
from_disp_str = false,
unibyte = false
},
w = 0xcfe5b0,
paragraph_dir = NEUTRAL_DIR,
separator_limit = 0,
first_elt = false,
new_paragraph = false,
frame_window_p = false
},
paragraph_embedding = L2R
}
height = <optimized out>
start = <optimized out>
window_height_changed_p = false
#6 0x0000000000434e42 in with_echo_area_buffer (w=0xcfe5b0, which=<optimized out>, fn=0x460f90 <resize_mini_window_1>, a1=13624752, a2=44448) at ../../src/xdisp.c:10609
buffer = 13936277
this_one = <optimized out>
the_other = <optimized out>
clear_buffer_p = false
rc = <optimized out>
#7 0x0000000000466e15 in resize_echo_area_exactly () at ../../src/xdisp.c:10857
resize_exactly = 0
resized_p = false
#8 0x000000000053848e in command_loop_1 () at ../../src/keyboard.c:1275
prev_modiff = 0
prev_buffer = 0x0
#9 0x00000000005abb16 in internal_condition_case (bfun=bfun@entry=0x5377e0 <command_loop_1>, handlers=handlers@entry=19056, hfun=hfun@entry=0x52bf60 <cmd_error>) at ../../src/eval.c:1309
val = 0
c = <optimized out>
#10 0x0000000000525e3c in command_loop_2 (ignore=ignore@entry=0) at ../../src/keyboard.c:1100
val = 0
#11 0x00000000005aba9b in internal_catch (tag=tag@entry=45840, func=func@entry=0x525e20 <command_loop_2>, arg=arg@entry=0) at ../../src/eval.c:1074
val = 0
c = <optimized out>
#12 0x0000000000525df9 in command_loop () at ../../src/keyboard.c:1079
No locals.
#13 0x000000000052baab in recursive_edit_1 () at ../../src/keyboard.c:685
val = <optimized out>
#14 0x000000000052be08 in Frecursive_edit () at ../../src/keyboard.c:756
buffer = <optimized out>
#15 0x00000000004135f7 in main (argc=13632916, argv=0x7fffffffe598) at ../../src/emacs.c:1605
dummy = 140737488348224
stack_bottom_variable = -1 '\377'
skip_args = 1
rlim = {
rlim_cur = 8720000,
rlim_max = 18446744073709551615
}
junk = 0x0
dname_arg = 0x0
ch_to_dir = 0x0
The emacs_abort call comes from bidi_initialize because the bidi_type_table result is nil.
1097 emacs_abort ();
1092 static void
1093 bidi_initialize (void)
1094 {
1095 bidi_type_table = uniprop_table (intern ("bidi-class"));
1096 if (NILP (bidi_type_table))
1097 emacs_abort ();
1098 staticpro (&bidi_type_table);
1099
1100 bidi_mirror_table = uniprop_table (intern ("mirroring"));
1101 if (NILP (bidi_mirror_table))
^ permalink raw reply [flat|nested] 26+ messages in thread* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-10 5:41 bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode Ken Raeburn
@ 2016-03-10 7:10 ` Eli Zaretskii
2016-03-10 7:39 ` Eli Zaretskii
0 siblings, 1 reply; 26+ messages in thread
From: Eli Zaretskii @ 2016-03-10 7:10 UTC (permalink / raw)
To: Ken Raeburn; +Cc: 22975
> From: Ken Raeburn <raeburn@raeburn.org>
> Date: Thu, 10 Mar 2016 00:41:50 -0500
>
> The emacs_abort call comes from bidi_initialize because the bidi_type_table result is nil.
>
> 1097 emacs_abort ();
> 1092 static void
> 1093 bidi_initialize (void)
> 1094 {
> 1095 bidi_type_table = uniprop_table (intern ("bidi-class"));
> 1096 if (NILP (bidi_type_table))
> 1097 emacs_abort ();
> 1098 staticpro (&bidi_type_table);
> 1099
> 1100 bidi_mirror_table = uniprop_table (intern ("mirroring"));
> 1101 if (NILP (bidi_mirror_table))
A build that CANNOT_DUMP should load loadup.el at startup. Does this
build do it?
When loadup.el is loaded it loads charprop.el. Does thi happen with
this build?
When charprop.el loads, it runs this code:
(define-char-code-property 'bidi-class "uni-bidi.el"
"Unicode bidi class.
Property value is one of the following symbols:
L, LRE, LRO, LRI, R, AL, RLE, RLO, RLI, FSI, PDF, PDI,
EN, ES, ET, AN, CS, NSM, BN, B, S, WS, ON")
When this code runs, it should load uni-bidi.el, which defines the
char-table accessed in the above snippet.
What I think happens in your case is that bidi_initialize is called
_before_ all of the above happens, probably because Emacs wants to
display some message in the echo area during loading loadup.el, or
maybe even earlier. If so, the solution should be to disable bidi
until loadup is done, and turn it on afterwards. One way of disabling
bidi is to (setq-default bidi-display-reordering nil) (or its C
equivalent) at the beginning of 'main', or maybe at the beginning of
loadup.el (if you can detect CANNOT_DUMP from Lisp). Then turn it
back on when loadup.el finishes by setting bidi-display-reordering to
t.
Can you try that?
^ permalink raw reply [flat|nested] 26+ messages in thread* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-10 7:10 ` Eli Zaretskii
@ 2016-03-10 7:39 ` Eli Zaretskii
2016-03-11 11:17 ` Ken Raeburn
0 siblings, 1 reply; 26+ messages in thread
From: Eli Zaretskii @ 2016-03-10 7:39 UTC (permalink / raw)
To: raeburn; +Cc: 22975
> Date: Thu, 10 Mar 2016 09:10:54 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 22975@debbugs.gnu.org
>
> What I think happens in your case is that bidi_initialize is called
> _before_ all of the above happens, probably because Emacs wants to
> display some message in the echo area during loading loadup.el, or
> maybe even earlier.
Actually, "./temacs -Q" with a build that doesn't define CANNOT_DUMP,
I should see the same problem. But in fact, I don't: the messages
from loadup.el are all displayed to the terminal, which doesn't use
bidi.c code, and the first time bidi_initialize is called is after
loadup.el was loaded in its entirety, and Emacs proceeds to creating
the first frame.
So some other factor is at work here. Please tell whether loadup.el
was already loaded at the point you got the abort, and if not, why is
Emacs trying to resize the mini-window so early?
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-10 7:39 ` Eli Zaretskii
@ 2016-03-11 11:17 ` Ken Raeburn
2016-03-11 14:31 ` Eli Zaretskii
0 siblings, 1 reply; 26+ messages in thread
From: Ken Raeburn @ 2016-03-11 11:17 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22975
It appears that Emacs tries to display the “Using load-path …” message, calls echo_area_display, display_echo_area, with_echo_area_buffer, display_echo_area_1, resize_mini_window, and grow_mini_window, which then uses
call3 (Qwindow_resize_root_window_vertically, …)
but since we haven’t loaded window.el yet, there’s no function definition and we raise a signal, quitting out of loadup and trying to display a message.
As to why normal temacs doesn’t show the problem: The load path displayed for a normal temacs contains one directory, but for a CANNOT_DUMP emacs it contains several; in my tests, resize_mini_window computed the height needed as one line for the former and six lines for the latter, so only in the latter case did grow_mini_window need to get called.
If I mess around with installation prefix length, window size, and font size, I can get the CANNOT_DUMP emacs to start properly (but with unreadably tiny characters); and if I make my terminal window quite narrow, I can get a normal temacs to get into some kind of error loop (not the same failure mode but probably a similar root cause). So it’s not just the CANNOT_DUMP setting that’s causing the problem.
Ken
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-11 11:17 ` Ken Raeburn
@ 2016-03-11 14:31 ` Eli Zaretskii
2016-03-11 19:18 ` Ken Raeburn
0 siblings, 1 reply; 26+ messages in thread
From: Eli Zaretskii @ 2016-03-11 14:31 UTC (permalink / raw)
To: Ken Raeburn; +Cc: 22975
> From: Ken Raeburn <raeburn@raeburn.org>
> Date: Fri, 11 Mar 2016 06:17:45 -0500
> Cc: 22975@debbugs.gnu.org
>
> It appears that Emacs tries to display the “Using load-path …” message, calls echo_area_display, display_echo_area, with_echo_area_buffer, display_echo_area_1, resize_mini_window, and grow_mini_window, which then uses
> call3 (Qwindow_resize_root_window_vertically, …)
> but since we haven’t loaded window.el yet, there’s no function definition and we raise a signal, quitting out of loadup and trying to display a message.
I'm not sure I follow: message calls message3_nolog, which should have
done this:
void
message3_nolog (Lisp_Object m)
{
struct frame *sf = SELECTED_FRAME ();
if (FRAME_INITIAL_P (sf))
message_to_stderr (m);
Is FRAME_INITIAL_P not doing it job in this case?
And just so I'm on the right page here: the "Loading foo..." messages
that loadup.el displays are shown where in this case? written to
stderr or displayed in the echo area?
> As to why normal temacs doesn’t show the problem: The load path displayed for a normal temacs contains one directory, but for a CANNOT_DUMP emacs it contains several; in my tests, resize_mini_window computed the height needed as one line for the former and six lines for the latter, so only in the latter case did grow_mini_window need to get called.
I think temacs should write these messages to stderr, so the whole
resize_mini_window rigmarole shouldn't get called at all. What am I
missing?
> If I mess around with installation prefix length, window size, and font size, I can get the CANNOT_DUMP emacs to start properly (but with unreadably tiny characters); and if I make my terminal window quite narrow, I can get a normal temacs to get into some kind of error loop (not the same failure mode but probably a similar root cause). So it’s not just the CANNOT_DUMP setting that’s causing the problem.
Error loop that displays what messages?
^ permalink raw reply [flat|nested] 26+ messages in thread* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-11 14:31 ` Eli Zaretskii
@ 2016-03-11 19:18 ` Ken Raeburn
2016-03-11 19:47 ` Eli Zaretskii
0 siblings, 1 reply; 26+ messages in thread
From: Ken Raeburn @ 2016-03-11 19:18 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22975
> On Mar 11, 2016, at 09:31, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> From: Ken Raeburn <raeburn@raeburn.org>
>> Date: Fri, 11 Mar 2016 06:17:45 -0500
>> Cc: 22975@debbugs.gnu.org
>>
>> It appears that Emacs tries to display the “Using load-path …” message, calls echo_area_display, display_echo_area, with_echo_area_buffer, display_echo_area_1, resize_mini_window, and grow_mini_window, which then uses
>> call3 (Qwindow_resize_root_window_vertically, …)
>> but since we haven’t loaded window.el yet, there’s no function definition and we raise a signal, quitting out of loadup and trying to display a message.
>
> I'm not sure I follow: message calls message3_nolog, which should have
> done this:
>
> void
> message3_nolog (Lisp_Object m)
> {
> struct frame *sf = SELECTED_FRAME ();
>
> if (FRAME_INITIAL_P (sf))
> message_to_stderr (m);
>
> Is FRAME_INITIAL_P not doing it job in this case?
With “-nw”, sf->output_method is output_termcap. It’s cleared the window and drawn a line of dashes near the bottom, and messages are displayed on the bottom line (when it’s not crashing).
Without “-nw”, sf->output_method is output_initial and messages are printed to stderr line by line until the X frame opens.
> And just so I'm on the right page here: the "Loading foo..." messages
> that loadup.el displays are shown where in this case? written to
> stderr or displayed in the echo area?
In the echo area.
>
>> As to why normal temacs doesn’t show the problem: The load path displayed for a normal temacs contains one directory, but for a CANNOT_DUMP emacs it contains several; in my tests, resize_mini_window computed the height needed as one line for the former and six lines for the latter, so only in the latter case did grow_mini_window need to get called.
>
> I think temacs should write these messages to stderr, so the whole
> resize_mini_window rigmarole shouldn't get called at all. What am I
> missing?
In init_display we call init_tty and then update the frame’s output_method. Under X11, the X frame creation happens much later.
>
>> If I mess around with installation prefix length, window size, and font size, I can get the CANNOT_DUMP emacs to start properly (but with unreadably tiny characters); and if I make my terminal window quite narrow, I can get a normal temacs to get into some kind of error loop (not the same failure mode but probably a similar root cause). So it’s not just the CANNOT_DUMP setting that’s causing the problem.
>
> Error loop that displays what messages?
*Tries* to display… From the stack trace, it looks like it’s throwing an error that window—-resize-root-window-vertically isn’t defined, then back at the top level we notice we’re displaying a message, so we call resize_echo_area_exactly, which decides to resize, which tries to call window—resize-root-window-vertically, etc.
Ken
^ permalink raw reply [flat|nested] 26+ messages in thread* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-11 19:18 ` Ken Raeburn
@ 2016-03-11 19:47 ` Eli Zaretskii
2016-03-11 20:50 ` Kenneth Raeburn
` (2 more replies)
0 siblings, 3 replies; 26+ messages in thread
From: Eli Zaretskii @ 2016-03-11 19:47 UTC (permalink / raw)
To: Ken Raeburn; +Cc: 22975
> From: Ken Raeburn <raeburn@raeburn.org>
> Date: Fri, 11 Mar 2016 14:18:55 -0500
> Cc: 22975@debbugs.gnu.org
>
> > On Mar 11, 2016, at 09:31, Eli Zaretskii <eliz@gnu.org> wrote:
> >
> >> From: Ken Raeburn <raeburn@raeburn.org>
> >> Date: Fri, 11 Mar 2016 06:17:45 -0500
> >> Cc: 22975@debbugs.gnu.org
> >>
> >> It appears that Emacs tries to display the “Using load-path …” message, calls echo_area_display, display_echo_area, with_echo_area_buffer, display_echo_area_1, resize_mini_window, and grow_mini_window, which then uses
> >> call3 (Qwindow_resize_root_window_vertically, …)
> >> but since we haven’t loaded window.el yet, there’s no function definition and we raise a signal, quitting out of loadup and trying to display a message.
> >
> > I'm not sure I follow: message calls message3_nolog, which should have
> > done this:
> >
> > void
> > message3_nolog (Lisp_Object m)
> > {
> > struct frame *sf = SELECTED_FRAME ();
> >
> > if (FRAME_INITIAL_P (sf))
> > message_to_stderr (m);
> >
> > Is FRAME_INITIAL_P not doing it job in this case?
>
> With “-nw”, sf->output_method is output_termcap. It’s cleared the window and drawn a line of dashes near the bottom, and messages are displayed on the bottom line (when it’s not crashing).
>
> Without “-nw”, sf->output_method is output_initial and messages are printed to stderr line by line until the X frame opens.
>
> > And just so I'm on the right page here: the "Loading foo..." messages
> > that loadup.el displays are shown where in this case? written to
> > stderr or displayed in the echo area?
>
> In the echo area.
>
> >
> >> As to why normal temacs doesn’t show the problem: The load path displayed for a normal temacs contains one directory, but for a CANNOT_DUMP emacs it contains several; in my tests, resize_mini_window computed the height needed as one line for the former and six lines for the latter, so only in the latter case did grow_mini_window need to get called.
> >
> > I think temacs should write these messages to stderr, so the whole
> > resize_mini_window rigmarole shouldn't get called at all. What am I
> > missing?
>
> In init_display we call init_tty and then update the frame’s output_method. Under X11, the X frame creation happens much later.
OK, I see. So now it's crystal clear that bidi-display-reordering
should be bound to nil until loadup finishes, otherwise we are
playing with fire.
Is there a way to know that the build CANNOT_DUMP from Lisp?
> > Error loop that displays what messages?
>
> *Tries* to display… From the stack trace, it looks like it’s throwing an error that window—-resize-root-window-vertically isn’t defined, then back at the top level we notice we’re displaying a message, so we call resize_echo_area_exactly, which decides to resize, which tries to call window—resize-root-window-vertically, etc.
Right, all is clear now.
Thanks.
^ permalink raw reply [flat|nested] 26+ messages in thread* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-11 19:47 ` Eli Zaretskii
@ 2016-03-11 20:50 ` Kenneth Raeburn
2016-03-11 20:51 ` Andreas Schwab
2016-03-15 18:29 ` Stefan Monnier
2 siblings, 0 replies; 26+ messages in thread
From: Kenneth Raeburn @ 2016-03-11 20:50 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22975
loadup.el has code testing (fboundp 'dump-emacs), it's not bound if CANNOT_DUMP is defined.
Ken
On Mar 11, 2016, at 14:47, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Ken Raeburn <raeburn@raeburn.org>
>> Date: Fri, 11 Mar 2016 14:18:55 -0500
>> Cc: 22975@debbugs.gnu.org
>>
>>>> On Mar 11, 2016, at 09:31, Eli Zaretskii <eliz@gnu.org> wrote:
>>>>
>>>> From: Ken Raeburn <raeburn@raeburn.org>
>>>> Date: Fri, 11 Mar 2016 06:17:45 -0500
>>>> Cc: 22975@debbugs.gnu.org
>>>>
>>>> It appears that Emacs tries to display the “Using load-path …” message, calls echo_area_display, display_echo_area, with_echo_area_buffer, display_echo_area_1, resize_mini_window, and grow_mini_window, which then uses
>>>> call3 (Qwindow_resize_root_window_vertically, …)
>>>> but since we haven’t loaded window.el yet, there’s no function definition and we raise a signal, quitting out of loadup and trying to display a message.
>>>
>>> I'm not sure I follow: message calls message3_nolog, which should have
>>> done this:
>>>
>>> void
>>> message3_nolog (Lisp_Object m)
>>> {
>>> struct frame *sf = SELECTED_FRAME ();
>>>
>>> if (FRAME_INITIAL_P (sf))
>>> message_to_stderr (m);
>>>
>>> Is FRAME_INITIAL_P not doing it job in this case?
>>
>> With “-nw”, sf->output_method is output_termcap. It’s cleared the window and drawn a line of dashes near the bottom, and messages are displayed on the bottom line (when it’s not crashing).
>>
>> Without “-nw”, sf->output_method is output_initial and messages are printed to stderr line by line until the X frame opens.
>>
>>> And just so I'm on the right page here: the "Loading foo..." messages
>>> that loadup.el displays are shown where in this case? written to
>>> stderr or displayed in the echo area?
>>
>> In the echo area.
>>
>>>
>>>> As to why normal temacs doesn’t show the problem: The load path displayed for a normal temacs contains one directory, but for a CANNOT_DUMP emacs it contains several; in my tests, resize_mini_window computed the height needed as one line for the former and six lines for the latter, so only in the latter case did grow_mini_window need to get called.
>>>
>>> I think temacs should write these messages to stderr, so the whole
>>> resize_mini_window rigmarole shouldn't get called at all. What am I
>>> missing?
>>
>> In init_display we call init_tty and then update the frame’s output_method. Under X11, the X frame creation happens much later.
>
> OK, I see. So now it's crystal clear that bidi-display-reordering
> should be bound to nil until loadup finishes, otherwise we are
> playing with fire.
>
> Is there a way to know that the build CANNOT_DUMP from Lisp?
>
>>> Error loop that displays what messages?
>>
>> *Tries* to display… From the stack trace, it looks like it’s throwing an error that window—-resize-root-window-vertically isn’t defined, then back at the top level we notice we’re displaying a message, so we call resize_echo_area_exactly, which decides to resize, which tries to call window—resize-root-window-vertically, etc.
>
> Right, all is clear now.
>
> Thanks.
^ permalink raw reply [flat|nested] 26+ messages in thread* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-11 19:47 ` Eli Zaretskii
2016-03-11 20:50 ` Kenneth Raeburn
@ 2016-03-11 20:51 ` Andreas Schwab
2016-03-11 21:06 ` Eli Zaretskii
2016-03-15 18:29 ` Stefan Monnier
2 siblings, 1 reply; 26+ messages in thread
From: Andreas Schwab @ 2016-03-11 20:51 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22975, Ken Raeburn
Eli Zaretskii <eliz@gnu.org> writes:
> OK, I see. So now it's crystal clear that bidi-display-reordering
> should be bound to nil until loadup finishes, otherwise we are
> playing with fire.
>
> Is there a way to know that the build CANNOT_DUMP from Lisp?
Would it be wrong to do this always? In temacs that is preparing to
dump the value of bidi-display-reordering should make no difference.
(A emacs that CANNOT_DUMP doesn't have dump-emacs.)
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."
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-11 20:51 ` Andreas Schwab
@ 2016-03-11 21:06 ` Eli Zaretskii
2016-03-12 10:01 ` Eli Zaretskii
0 siblings, 1 reply; 26+ messages in thread
From: Eli Zaretskii @ 2016-03-11 21:06 UTC (permalink / raw)
To: Andreas Schwab; +Cc: 22975, raeburn
> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Ken Raeburn <raeburn@raeburn.org>, 22975@debbugs.gnu.org
> Date: Fri, 11 Mar 2016 21:51:04 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > OK, I see. So now it's crystal clear that bidi-display-reordering
> > should be bound to nil until loadup finishes, otherwise we are
> > playing with fire.
> >
> > Is there a way to know that the build CANNOT_DUMP from Lisp?
>
> Would it be wrong to do this always?
I didn't mean to say it wasn't; the above 2 questions are 2 separate
issues.
> In temacs that is preparing to dump the value of
> bidi-display-reordering should make no difference.
You are right about -batch, but when temacs is run with -nw, we will
probably want to turn reordering on as soon as we can, because some
file or directory name, or maybe some message displayed during
loading, might require reordering. (Being able to run "./temacs -nw"
is an important capability for debugging problems that happen due to
dumping.) In fact, turning reordering off will display load path
incorrectly, if it includes R2L characters, but I see no way around
that (and I think when we display that, we don't yet have encoding and
decoding of file names set up, so we cannot reorder anyway).
> (A emacs that CANNOT_DUMP doesn't have dump-emacs.)
Right, thanks.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-11 21:06 ` Eli Zaretskii
@ 2016-03-12 10:01 ` Eli Zaretskii
2016-03-13 1:21 ` Ken Raeburn
0 siblings, 1 reply; 26+ messages in thread
From: Eli Zaretskii @ 2016-03-12 10:01 UTC (permalink / raw)
To: raeburn; +Cc: 22975, schwab
> Date: Fri, 11 Mar 2016 23:06:25 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 22975@debbugs.gnu.org, raeburn@raeburn.org
>
> > From: Andreas Schwab <schwab@linux-m68k.org>
> > Cc: Ken Raeburn <raeburn@raeburn.org>, 22975@debbugs.gnu.org
> > Date: Fri, 11 Mar 2016 21:51:04 +0100
> >
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> > > OK, I see. So now it's crystal clear that bidi-display-reordering
> > > should be bound to nil until loadup finishes, otherwise we are
> > > playing with fire.
> > >
> > > Is there a way to know that the build CANNOT_DUMP from Lisp?
> >
> > Would it be wrong to do this always?
>
> I didn't mean to say it wasn't; the above 2 questions are 2 separate
> issues.
It turns out we already had protection for this: xdisp.c was looking
at the value of purify-flag to decide when it is safe to perform bidi
reordering. That protection was added to fix bug#9963.
However, a change in Dec 2013 made purify-flag be nil on systems that
CANNOT_DUMP when they process loadup.el, so that protection was lost
on those systems.
I've now added a special variable for this purpose, and changed the
display engine to use it instead of purify-flag. Ken, could you
please see if the latest emacs-25 branch resolves the original problem
you reported? If Emacs succeeds to start in tty mode after these
changes, please type "C-h H" and see if the Arabic and Hebrew
greetings are displayed correctly reordered (moving cursor with C-f
across those parts should move right-to-left when point is inside
those words).
Thanks.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-12 10:01 ` Eli Zaretskii
@ 2016-03-13 1:21 ` Ken Raeburn
2016-03-13 12:08 ` martin rudalics
2016-03-13 16:45 ` Eli Zaretskii
0 siblings, 2 replies; 26+ messages in thread
From: Ken Raeburn @ 2016-03-13 1:21 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22975, schwab
> It turns out we already had protection for this: xdisp.c was looking
> at the value of purify-flag to decide when it is safe to perform bidi
> reordering. That protection was added to fix bug#9963.
>
> However, a change in Dec 2013 made purify-flag be nil on systems that
> CANNOT_DUMP when they process loadup.el, so that protection was lost
> on those systems.
>
> I've now added a special variable for this purpose, and changed the
> display engine to use it instead of purify-flag. Ken, could you
> please see if the latest emacs-25 branch resolves the original problem
> you reported? If Emacs succeeds to start in tty mode after these
> changes, please type "C-h H" and see if the Arabic and Hebrew
> greetings are displayed correctly reordered (moving cursor with C-f
> across those parts should move right-to-left when point is inside
> those words).
In X11 mode, both the normal and CANNOT_DUMP versions seem to work fine now, and the cursor motion with C-f in the hello buffer is as you describe.
In tty mode, the normal version starts fine, and the cursor motion is mostly as you describe, though the Arabic and Hebrew text don’t look the same in the terminal emulator (Mac terminal emulator running ssh to a GNU/Linux box running Emacs) as in the X11 window. Instead, it looks like, for example, everything after “Hebrew (” on that line is reversed from the X11 display, and the “)” replaced with “(”. Also, the cursor positioning as I hit C-f or C-b doesn’t quite line up with where the characters are; I think it may be lining up with where it thinks they’d be if they were laid out as in the X11 display. So it moves over whitespace here, skips a character there…
In tty mode, the CANNOT_DUMP version get stuck in a loop at startup complaining that internal-echo-keystrokes-prefix isn’t defined. If I set a breakpoint on Fsignal, it’s first complaining about window--resize-root-window-vertically when trying to display the long load path, presumably terminating the processing of loadup.el; the second time it’s internal-timer-start-idle, then internal-echo-keystrokes-prefix, and then we just seem to stick with that one from then on.
So, at least the abort’s gone; that’s something…. :-)
Obviously the long message lines need to be handled, or at least need to not cause us to error out of the startup. Maybe C or Lisp could define a simple, dumb version of window--resize-root-window-vertically that gets us past this point? That might be cheaper than testing on every call to verify that the function has been defined so that we can fall back to some other behavior in this rare case.
Given how much even basic operation depends on various bits of Lisp code being available, I’m starting to think that if loadup.el cannot load successfully (with the possible exception of site initialization files), maybe Emacs should just refuse to start, instead of continuing on to the top level loop.
Ken
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-13 1:21 ` Ken Raeburn
@ 2016-03-13 12:08 ` martin rudalics
2016-03-13 16:46 ` Eli Zaretskii
2016-03-13 16:45 ` Eli Zaretskii
1 sibling, 1 reply; 26+ messages in thread
From: martin rudalics @ 2016-03-13 12:08 UTC (permalink / raw)
To: Ken Raeburn, Eli Zaretskii; +Cc: 22975, schwab
> In tty mode, the CANNOT_DUMP version get stuck in a loop at startup
> complaining that internal-echo-keystrokes-prefix isn’t defined. If I
> set a breakpoint on Fsignal, it’s first complaining about
> window--resize-root-window-vertically when trying to display the long
> load path, presumably terminating the processing of loadup.el;
Can you please try adding a placeholder function like Paul did with
Fframe_windows_min_size and Fwindow__sanitize_window_sizes.
Thanks, martin
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-13 12:08 ` martin rudalics
@ 2016-03-13 16:46 ` Eli Zaretskii
2016-03-13 20:09 ` martin rudalics
0 siblings, 1 reply; 26+ messages in thread
From: Eli Zaretskii @ 2016-03-13 16:46 UTC (permalink / raw)
To: martin rudalics; +Cc: 22975, raeburn, schwab
> Date: Sun, 13 Mar 2016 13:08:06 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: 22975@debbugs.gnu.org, schwab@linux-m68k.org
>
> > In tty mode, the CANNOT_DUMP version get stuck in a loop at startup
> > complaining that internal-echo-keystrokes-prefix isn’t defined. If I
> > set a breakpoint on Fsignal, it’s first complaining about
> > window--resize-root-window-vertically when trying to display the long
> > load path, presumably terminating the processing of loadup.el;
>
> Can you please try adding a placeholder function like Paul did with
> Fframe_windows_min_size and Fwindow__sanitize_window_sizes.
How can we know what these placeholders should do, without seeing
which code calls them?
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-13 16:46 ` Eli Zaretskii
@ 2016-03-13 20:09 ` martin rudalics
2016-03-13 20:31 ` Eli Zaretskii
0 siblings, 1 reply; 26+ messages in thread
From: martin rudalics @ 2016-03-13 20:09 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22975, raeburn, schwab
>> > In tty mode, the CANNOT_DUMP version get stuck in a loop at startup
>> > complaining that internal-echo-keystrokes-prefix isn’t defined. If I
>> > set a breakpoint on Fsignal, it’s first complaining about
>> > window--resize-root-window-vertically when trying to display the long
>> > load path, presumably terminating the processing of loadup.el;
>>
>> Can you please try adding a placeholder function like Paul did with
>> Fframe_windows_min_size and Fwindow__sanitize_window_sizes.
>
> How can we know what these placeholders should do, without seeing
> which code calls them?
The idea was that if Ken's assumption is right that complaining about
window--resize-root-window-vertically terminates the processing of
loadup.el, then such a placeholder function (that would do nothing)
would have allowed it to proceed ...
martin
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-13 20:09 ` martin rudalics
@ 2016-03-13 20:31 ` Eli Zaretskii
2016-03-14 7:42 ` martin rudalics
0 siblings, 1 reply; 26+ messages in thread
From: Eli Zaretskii @ 2016-03-13 20:31 UTC (permalink / raw)
To: martin rudalics; +Cc: 22975, raeburn, schwab
> Date: Sun, 13 Mar 2016 21:09:26 +0100
> From: martin rudalics <rudalics@gmx.at>
> CC: raeburn@raeburn.org, 22975@debbugs.gnu.org, schwab@linux-m68k.org
>
> >> > In tty mode, the CANNOT_DUMP version get stuck in a loop at startup
> >> > complaining that internal-echo-keystrokes-prefix isn’t defined. If I
> >> > set a breakpoint on Fsignal, it’s first complaining about
> >> > window--resize-root-window-vertically when trying to display the long
> >> > load path, presumably terminating the processing of loadup.el;
> >>
> >> Can you please try adding a placeholder function like Paul did with
> >> Fframe_windows_min_size and Fwindow__sanitize_window_sizes.
> >
> > How can we know what these placeholders should do, without seeing
> > which code calls them?
>
> The idea was that if Ken's assumption is right that complaining about
> window--resize-root-window-vertically terminates the processing of
> loadup.el, then such a placeholder function (that would do nothing)
> would have allowed it to proceed ...
But the return value might need to be something specific to steer the
rest of execution where we want it. For example, grow_mini_window
does this:
if (delta > 0)
{
root = FRAME_ROOT_WINDOW (f);
r = XWINDOW (root);
height = call3 (Qwindow_resize_root_window_vertically,
root, make_number (- delta), pixelwise ? Qt : Qnil);
if (INTEGERP (height) && window_resize_check (r, false))
{
block_input ();
window_resize_apply (r, false);
which means we need the placeholder return nil to do what we want. If
it returns something else, who knows what will happen next?
IOW, we need to study the actual calls to know what to do in the
placeholders. The same examination could tell us how to avoid the
calls to those functions altogether. E.g., binding
resize-mini-windows to nil around the code that runs loadup.el would
prevent the call to grow_mini_window in the first place. Maybe that's
better, I didn't yet make up my mind.
^ permalink raw reply [flat|nested] 26+ messages in thread* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-13 20:31 ` Eli Zaretskii
@ 2016-03-14 7:42 ` martin rudalics
0 siblings, 0 replies; 26+ messages in thread
From: martin rudalics @ 2016-03-14 7:42 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22975, raeburn, schwab
> But the return value might need to be something specific to steer the
> rest of execution where we want it. For example, grow_mini_window
> does this:
>
> if (delta > 0)
> {
> root = FRAME_ROOT_WINDOW (f);
> r = XWINDOW (root);
> height = call3 (Qwindow_resize_root_window_vertically,
> root, make_number (- delta), pixelwise ? Qt : Qnil);
> if (INTEGERP (height) && window_resize_check (r, false))
> {
> block_input ();
> window_resize_apply (r, false);
>
> which means we need the placeholder return nil to do what we want. If
> it returns something else, who knows what will happen next?
If it doesn't return an integer, this check
if (INTEGERP (height) && window_resize_check (r, false))
will fail and nothing will happen.
> IOW, we need to study the actual calls to know what to do in the
> placeholders. The same examination could tell us how to avoid the
> calls to those functions altogether. E.g., binding
> resize-mini-windows to nil around the code that runs loadup.el would
> prevent the call to grow_mini_window in the first place. Maybe that's
> better, I didn't yet make up my mind.
This would be probably better. Mine was just a proposal to work around
the current situation without any definitive fix.
martin
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-13 1:21 ` Ken Raeburn
2016-03-13 12:08 ` martin rudalics
@ 2016-03-13 16:45 ` Eli Zaretskii
2016-03-14 7:17 ` Ken Raeburn
1 sibling, 1 reply; 26+ messages in thread
From: Eli Zaretskii @ 2016-03-13 16:45 UTC (permalink / raw)
To: Ken Raeburn; +Cc: 22975, schwab
> From: Ken Raeburn <raeburn@raeburn.org>
> Date: Sat, 12 Mar 2016 20:21:35 -0500
> Cc: schwab@linux-m68k.org,
> 22975@debbugs.gnu.org
>
> In X11 mode, both the normal and CANNOT_DUMP versions seem to work fine now, and the cursor motion with C-f in the hello buffer is as you describe.
That's a start.
> In tty mode, the normal version starts fine, and the cursor motion is mostly as you describe, though the Arabic and Hebrew text don’t look the same in the terminal emulator (Mac terminal emulator running ssh to a GNU/Linux box running Emacs) as in the X11 window. Instead, it looks like, for example, everything after “Hebrew (” on that line is reversed from the X11 display, and the “)” replaced with “(”. Also, the cursor positioning as I hit C-f or C-b doesn’t quite line up with where the characters are; I think it may be lining up with where it thinks they’d be if they were laid out as in the X11 display. So it moves over whitespace here, skips a character there…
Can you show a screenshot?
It sounds like your terminal emulator is trying its own reordering of
bidi text. Can you find some setting to disable that?
In any case, this is unrelated to the issue at hand.
> In tty mode, the CANNOT_DUMP version get stuck in a loop at startup complaining that internal-echo-keystrokes-prefix isn’t defined. If I set a breakpoint on Fsignal, it’s first complaining about window--resize-root-window-vertically when trying to display the long load path, presumably terminating the processing of loadup.el; the second time it’s internal-timer-start-idle, then internal-echo-keystrokes-prefix, and then we just seem to stick with that one from then on.
Please show a full C backtrace from each one of the calls to Fsignal,
so we could see what code calls these functions.
> Obviously the long message lines need to be handled, or at least need to not cause us to error out of the startup. Maybe C or Lisp could define a simple, dumb version of window--resize-root-window-vertically that gets us past this point? That might be cheaper than testing on every call to verify that the function has been defined so that we can fall back to some other behavior in this rare case.
Let's defer this discussion till after we see the backtraces.
In general, the above is the price we pay for moving more basic stuff
to Lisp. But I very much doubt that these problem cannot have some
simple solution. Whether dumb versions in C are it, I don't know: it
depends on who calls them and what does that code expect from the
call.
> Given how much even basic operation depends on various bits of Lisp code being available, I’m starting to think that if loadup.el cannot load successfully (with the possible exception of site initialization files), maybe Emacs should just refuse to start, instead of continuing on to the top level loop.
No, I don't think so: aborting will remove the error messages and
other phenomena that are needed to debug these problems.
Thanks.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-13 16:45 ` Eli Zaretskii
@ 2016-03-14 7:17 ` Ken Raeburn
2016-03-14 17:41 ` Eli Zaretskii
0 siblings, 1 reply; 26+ messages in thread
From: Ken Raeburn @ 2016-03-14 7:17 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22975, Andreas Schwab
[-- Attachment #1: Type: text/plain, Size: 11411 bytes --]
>> In tty mode, the normal version starts fine, and the cursor motion is mostly as you describe, though the Arabic and Hebrew text don’t look the same in the terminal emulator (Mac terminal emulator running ssh to a GNU/Linux box running Emacs) as in the X11 window. Instead, it looks like, for example, everything after “Hebrew (” on that line is reversed from the X11 display, and the “)” replaced with “(”. Also, the cursor positioning as I hit C-f or C-b doesn’t quite line up with where the characters are; I think it may be lining up with where it thinks they’d be if they were laid out as in the X11 display. So it moves over whitespace here, skips a character there…
>
> Can you show a screenshot?
>
> It sounds like your terminal emulator is trying its own reordering of
> bidi text. Can you find some setting to disable that?
I can’t find an option to change it in the Mac terminal emulator. I hope the attached image doesn’t make for headaches in the bug tracker….
If I start a standard X.org xterm from the remote system and run emacs -nw in that window, the Hebrew line looks like it does on the X11 display; Arabic seems to be missing font support.
> In any case, this is unrelated to the issue at hand.
>
>> In tty mode, the CANNOT_DUMP version get stuck in a loop at startup complaining that internal-echo-keystrokes-prefix isn’t defined. If I set a breakpoint on Fsignal, it’s first complaining about window--resize-root-window-vertically when trying to display the long load path, presumably terminating the processing of loadup.el; the second time it’s internal-timer-start-idle, then internal-echo-keystrokes-prefix, and then we just seem to stick with that one from then on.
>
> Please show a full C backtrace from each one of the calls to Fsignal,
> so we could see what code calls these functions.
#0 Fsignal (error_symbol=error_symbol@entry=49392, data=12582931)
at ../../src/eval.c:1464
#1 0x0000000000552fd9 in xsignal (error_symbol=error_symbol@entry=49392,
data=<optimized out>) at ../../src/eval.c:1577
#2 0x0000000000553007 in xsignal1 (error_symbol=49392, arg=<optimized out>)
at ../../src/eval.c:1592
#3 0x0000000000552612 in Ffuncall (nargs=49392, nargs@entry=4, args=0x0)
at ../../src/eval.c:2746
#4 0x0000000000554204 in call3 (fn=fn@entry=50592, arg1=arg1@entry=12481485,
arg2=<optimized out>, arg3=<optimized out>) at ../../src/eval.c:2568
#5 0x0000000000472717 in grow_mini_window (w=0xbe75b0, delta=<optimized out>,
pixelwise=<optimized out>) at ../../src/window.c:4501
#6 0x000000000044bd32 in resize_mini_window (w=w@entry=0xbe75b0,
exact_p=exact_p@entry=false) at ../../src/xdisp.c:10985
#7 0x000000000044bd8e in display_echo_area_1 (a1=12481968, a2=<optimized out>)
at ../../src/xdisp.c:10831
#8 0x000000000042b8f6 in with_echo_area_buffer (w=w@entry=0xbe75b0,
which=which@entry=0, fn=fn@entry=0x44bd50 <display_echo_area_1>,
a1=a1@entry=12481968, a2=a2@entry=0) at ../../src/xdisp.c:10609
#9 0x000000000044f46b in display_echo_area (w=0xbe75b0)
at ../../src/xdisp.c:10797
#10 echo_area_display (update_frame_p=update_frame_p@entry=true)
at ../../src/xdisp.c:11298
#11 0x000000000044f76a in message3_nolog (m=m@entry=12803636)
at ../../src/xdisp.c:10311
#12 0x000000000044f8b1 in message3 (m=m@entry=12803636)
at ../../src/xdisp.c:10240
#13 0x000000000054c31c in Fmessage (nargs=<optimized out>, args=<optimized out>)
at ../../src/editfns.c:3686
#14 0x0000000000551ff0 in eval_sub (form=form@entry=12584899)
at ../../src/eval.c:2137
#15 0x000000000057475f in readevalloop (readcharfun=24528, stream=0xbed7f0,
sourcename=12773572, printflag=false, unibyte=<optimized out>, readfun=0,
start=0, end=0) at ../../src/lread.c:1923
#16 0x0000000000574dec in Fload (file=49392, noerror=0, nomessage=0,
nosuffix=12773572, must_suffix=0) at ../../src/lread.c:1331
#17 0x0000000000551e89 in eval_sub (form=form@entry=12586851)
at ../../src/eval.c:2180
#18 0x00000000005550a1 in Feval (form=12586851, lexical=<optimized out>)
at ../../src/eval.c:1988
#19 0x0000000000551286 in internal_condition_case (
bfun=bfun@entry=0x4e1fa0 <top_level_2>, handlers=handlers@entry=19056,
hfun=hfun@entry=0x4e67e0 <cmd_error>) at ../../src/eval.c:1309
#20 0x00000000004e45cc in top_level_1 (ignore=ignore@entry=0)
at ../../src/keyboard.c:1117
#21 0x000000000055120b in internal_catch (tag=tag@entry=45840,
func=func@entry=0x4e4570 <top_level_1>, arg=arg@entry=0)
at ../../src/eval.c:1074
#22 0x00000000004e1f38 in command_loop () at ../../src/keyboard.c:1078
#23 0x00000000004e63eb in recursive_edit_1 () at ../../src/keyboard.c:685
#24 0x00000000004e6710 in Frecursive_edit () at ../../src/keyboard.c:756
#25 0x0000000000412244 in main (argc=3, argv=0x7fffffffe5b8)
at ../../src/emacs.c:1605
Lisp Backtrace:
"window--resize-root-window-vertically" (0xffffc8e8)
"message" (0xffffdfa0)
"load" (0xffffe2f0)
----------------
#0 Fsignal (error_symbol=error_symbol@entry=49392, data=12582483)
at ../../src/eval.c:1464
#1 0x0000000000552fd9 in xsignal (error_symbol=error_symbol@entry=49392,
data=<optimized out>) at ../../src/eval.c:1577
#2 0x0000000000553007 in xsignal1 (error_symbol=49392, arg=<optimized out>)
at ../../src/eval.c:1592
#3 0x0000000000552612 in Ffuncall (nargs=49392, nargs@entry=1, args=0x0)
at ../../src/eval.c:2746
#4 0x00000000005529b8 in call0 (fn=525424) at ../../src/eval.c:2544
#5 0x00000000004e4636 in timer_start_idle () at ../../src/keyboard.c:4242
#6 0x00000000004ed07c in timer_start_idle () at ../../src/keyboard.c:4077
#7 read_char (commandflag=49392, commandflag@entry=1, map=12582483,
map@entry=12582211, prev_event=24, used_mouse_menu=0x250,
used_mouse_menu@entry=0x7fffffffe18b, end_time=0xc2cf88, end_time@entry=0x0)
at ../../src/keyboard.c:2600
#8 0x00000000004edef6 in read_key_sequence (
keybuf=keybuf@entry=0x7fffffffe260, prompt=prompt@entry=0,
dont_downcase_last=dont_downcase_last@entry=false,
can_return_switch_frame=can_return_switch_frame@entry=true,
fix_current_buffer=fix_current_buffer@entry=true,
prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
at ../../src/keyboard.c:9054
#9 0x00000000004ef9f6 in command_loop_1 () at ../../src/keyboard.c:1358
#10 0x0000000000551286 in internal_condition_case (
bfun=bfun@entry=0x4ef800 <command_loop_1>, handlers=handlers@entry=19056,
hfun=hfun@entry=0x4e67e0 <cmd_error>) at ../../src/eval.c:1309
#11 0x00000000004e1f8c in command_loop_2 (ignore=ignore@entry=0)
at ../../src/keyboard.c:1100
#12 0x000000000055120b in internal_catch (tag=tag@entry=45840,
func=func@entry=0x4e1f70 <command_loop_2>, arg=arg@entry=0)
at ../../src/eval.c:1074
#13 0x00000000004e1f49 in command_loop () at ../../src/keyboard.c:1079
#14 0x00000000004e63eb in recursive_edit_1 () at ../../src/keyboard.c:685
#15 0x00000000004e6710 in Frecursive_edit () at ../../src/keyboard.c:756
#16 0x0000000000412244 in main (argc=3, argv=0x7fffffffe5b8)
at ../../src/emacs.c:1605
Lisp Backtrace:
"internal-timer-start-idle" (0xffffdb10)
----------------
#0 Fsignal (error_symbol=error_symbol@entry=49392, data=12826339)
at ../../src/eval.c:1464
#1 0x0000000000552fd9 in xsignal (error_symbol=error_symbol@entry=49392,
data=<optimized out>) at ../../src/eval.c:1577
#2 0x0000000000553007 in xsignal1 (error_symbol=49392, arg=<optimized out>)
at ../../src/eval.c:1592
#3 0x0000000000552612 in Ffuncall (nargs=49392, nargs@entry=1, args=0x0)
at ../../src/eval.c:2746
#4 0x00000000005529b8 in call0 (fn=28368) at ../../src/eval.c:2544
#5 0x00000000004ed2fe in read_char (commandflag=49392, commandflag@entry=1,
map=12826339, map@entry=12826307, prev_event=15, used_mouse_menu=0x2e0,
used_mouse_menu@entry=0x7fffffffe18b, end_time=0x3, end_time@entry=0x0)
at ../../src/keyboard.c:2609
#6 0x00000000004edef6 in read_key_sequence (
keybuf=keybuf@entry=0x7fffffffe260, prompt=prompt@entry=0,
dont_downcase_last=dont_downcase_last@entry=false,
can_return_switch_frame=can_return_switch_frame@entry=true,
fix_current_buffer=fix_current_buffer@entry=true,
prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
at ../../src/keyboard.c:9054
#7 0x00000000004ef9f6 in command_loop_1 () at ../../src/keyboard.c:1358
#8 0x0000000000551286 in internal_condition_case (
bfun=bfun@entry=0x4ef800 <command_loop_1>, handlers=handlers@entry=19056,
hfun=hfun@entry=0x4e67e0 <cmd_error>) at ../../src/eval.c:1309
#9 0x00000000004e1f8c in command_loop_2 (ignore=ignore@entry=0)
at ../../src/keyboard.c:1100
#10 0x000000000055120b in internal_catch (tag=tag@entry=45840,
func=func@entry=0x4e1f70 <command_loop_2>, arg=arg@entry=0)
at ../../src/eval.c:1074
#11 0x00000000004e1f49 in command_loop () at ../../src/keyboard.c:1079
#12 0x00000000004e63eb in recursive_edit_1 () at ../../src/keyboard.c:685
#13 0x00000000004e6710 in Frecursive_edit () at ../../src/keyboard.c:756
#14 0x0000000000412244 in main (argc=3, argv=0x7fffffffe5b8)
at ../../src/emacs.c:1605
Lisp Backtrace:
"internal-echo-keystrokes-prefix" (0xffffdb30)
>
>> Obviously the long message lines need to be handled, or at least need to not cause us to error out of the startup. Maybe C or Lisp could define a simple, dumb version of window--resize-root-window-vertically that gets us past this point? That might be cheaper than testing on every call to verify that the function has been defined so that we can fall back to some other behavior in this rare case.
>
> Let's defer this discussion till after we see the backtraces.
>
> In general, the above is the price we pay for moving more basic stuff
> to Lisp. But I very much doubt that these problem cannot have some
> simple solution. Whether dumb versions in C are it, I don't know: it
> depends on who calls them and what does that code expect from the
> call.
After glancing at the code you and Martin discussed, as a quick experiment, I did try adding:
(fset 'window--resize-root-window-vertically '(lambda (&rest ignored)))
to loadup.el before it prints the load path, and the CANNOT_DUMP emacs seems to have started up okay… as long as I didn’t make the window so narrow that the “Loading loadup” message itself was too wide and required wrapping. Since the Lisp files can't control things any earlier than that, I think the stub version, if we use one, ought to be in C.
>> Given how much even basic operation depends on various bits of Lisp code being available, I’m starting to think that if loadup.el cannot load successfully (with the possible exception of site initialization files), maybe Emacs should just refuse to start, instead of continuing on to the top level loop.
>
> No, I don't think so: aborting will remove the error messages and
> other phenomena that are needed to debug these problems.
I’d assume we’d print out error messages when quitting. But if we want to keep Emacs running enough to interactively pull out other information, it looks like we’re going to have to have stub versions of a few more routines.
[-- Attachment #2.1: Type: text/html, Size: 15592 bytes --]
[-- Attachment #2.2: Screen Shot 2016-03-14 at 01.30.15.png --]
[-- Type: image/png, Size: 127232 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-14 7:17 ` Ken Raeburn
@ 2016-03-14 17:41 ` Eli Zaretskii
2016-03-15 3:33 ` Ken Raeburn
0 siblings, 1 reply; 26+ messages in thread
From: Eli Zaretskii @ 2016-03-14 17:41 UTC (permalink / raw)
To: Ken Raeburn; +Cc: 22975, schwab
> From: Ken Raeburn <raeburn@raeburn.org>
> Date: Mon, 14 Mar 2016 03:17:07 -0400
> Cc: Andreas Schwab <schwab@linux-m68k.org>,
> 22975@debbugs.gnu.org
>
> > It sounds like your terminal emulator is trying its own reordering of
> > bidi text. Can you find some setting to disable that?
>
> I can’t find an option to change it in the Mac terminal emulator. I hope the attached image doesn’t make for headaches in the bug tracker….
Thanks. It does indeed reorder on its own (and doesn't do a very good
job at that). So this is unrelated.
> If I start a standard X.org xterm from the remote system and run emacs -nw in that window, the Hebrew line looks like it does on the X11 display; Arabic seems to be missing font support.
Right.
> > Please show a full C backtrace from each one of the calls to Fsignal,
> > so we could see what code calls these functions.
>
> #0 Fsignal (error_symbol=error_symbol@entry=49392, data=12582931)
> at ../../src/eval.c:1464
> #1 0x0000000000552fd9 in xsignal (error_symbol=error_symbol@entry=49392,
> data=<optimized out>) at ../../src/eval.c:1577
> #2 0x0000000000553007 in xsignal1 (error_symbol=49392, arg=<optimized out>)
> at ../../src/eval.c:1592
> #3 0x0000000000552612 in Ffuncall (nargs=49392, nargs@entry=4, args=0x0)
> at ../../src/eval.c:2746
> #4 0x0000000000554204 in call3 (fn=fn@entry=50592, arg1=arg1@entry=12481485,
> arg2=<optimized out>, arg3=<optimized out>) at ../../src/eval.c:2568
> #5 0x0000000000472717 in grow_mini_window (w=0xbe75b0, delta=<optimized out>,
> pixelwise=<optimized out>) at ../../src/window.c:4501
> #6 0x000000000044bd32 in resize_mini_window (w=w@entry=0xbe75b0,
> exact_p=exact_p@entry=false) at ../../src/xdisp.c:10985
> #7 0x000000000044bd8e in display_echo_area_1 (a1=12481968, a2=<optimized out>)
> at ../../src/xdisp.c:10831
> #8 0x000000000042b8f6 in with_echo_area_buffer (w=w@entry=0xbe75b0,
> which=which@entry=0, fn=fn@entry=0x44bd50 <display_echo_area_1>,
> a1=a1@entry=12481968, a2=a2@entry=0) at ../../src/xdisp.c:10609
> #9 0x000000000044f46b in display_echo_area (w=0xbe75b0)
> at ../../src/xdisp.c:10797
> #10 echo_area_display (update_frame_p=update_frame_p@entry=true)
> at ../../src/xdisp.c:11298
> #11 0x000000000044f76a in message3_nolog (m=m@entry=12803636)
> at ../../src/xdisp.c:10311
> #12 0x000000000044f8b1 in message3 (m=m@entry=12803636)
> at ../../src/xdisp.c:10240
> #13 0x000000000054c31c in Fmessage (nargs=<optimized out>, args=<optimized out>)
> at ../../src/editfns.c:3686
OK, this is the message call. Please see if the patch below solves
this.
The other two errors come from the command loop, they are caused by
the fact that calling message signaled an error, and that interrupted
the rest of loadup.el loading. So Emacs now enters the command loop
with most of its support code absent.
If the patch below solves the error in calling message, it should also
prevent these other 2 errors.
diff --git a/lisp/loadup.el b/lisp/loadup.el
index bd47bed..21c64a8 100644
--- a/lisp/loadup.el
+++ b/lisp/loadup.el
@@ -117,6 +117,10 @@
(load "format")
(load "bindings")
(load "window") ; Needed here for `replace-buffer-in-windows'.
+;; We are now capable of resizing the mini-windows, so give the
+;; variable its advertised default value (it starts as nil, see
+;; xdisp.c).
+(setq resize-mini-windows 'grow-only)
(setq load-source-file-function 'load-with-code-conversion)
(load "files")
diff --git a/src/xdisp.c b/src/xdisp.c
index ce992d4..edefe32 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -31598,7 +31598,12 @@ A value of t means resize them to fit the text displayed in them.
A value of `grow-only', the default, means let mini-windows grow only;
they return to their normal size when the minibuffer is closed, or the
echo area becomes empty. */);
- Vresize_mini_windows = Qgrow_only;
+ /* Contrary to the doc string, we initialize this to nil, so that
+ loading loadup.el won't try to resize windows before loading
+ window.el, where some functions we need to call for this live.
+ We assign the 'grow-only' value right after loading window.el
+ during loadup. */
+ Vresize_mini_windows = Qnil;
DEFVAR_LISP ("blink-cursor-alist", Vblink_cursor_alist,
doc: /* Alist specifying how to blink the cursor off.
^ permalink raw reply related [flat|nested] 26+ messages in thread* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-14 17:41 ` Eli Zaretskii
@ 2016-03-15 3:33 ` Ken Raeburn
2016-03-15 17:48 ` Eli Zaretskii
0 siblings, 1 reply; 26+ messages in thread
From: Ken Raeburn @ 2016-03-15 3:33 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22975, schwab
On Mar 14, 2016, at 13:41, Eli Zaretskii <eliz@gnu.org> wrote:
> OK, this is the message call. Please see if the patch below solves
> this.
>
> The other two errors come from the command loop, they are caused by
> the fact that calling message signaled an error, and that interrupted
> the rest of loadup.el loading. So Emacs now enters the command loop
> with most of its support code absent.
>
> If the patch below solves the error in calling message, it should also
> prevent these other 2 errors.
Yes, with that patch the emacs-25 branch starts up fine — X11 mode and tty mode (including in a way-too-narrow window), normal and CANNOT_DUMP.
Ken
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-15 3:33 ` Ken Raeburn
@ 2016-03-15 17:48 ` Eli Zaretskii
0 siblings, 0 replies; 26+ messages in thread
From: Eli Zaretskii @ 2016-03-15 17:48 UTC (permalink / raw)
To: Ken Raeburn; +Cc: 22975-done
> From: Ken Raeburn <raeburn@raeburn.org>
> Date: Mon, 14 Mar 2016 23:33:33 -0400
> Cc: schwab@linux-m68k.org,
> 22975@debbugs.gnu.org
>
> On Mar 14, 2016, at 13:41, Eli Zaretskii <eliz@gnu.org> wrote:
> > OK, this is the message call. Please see if the patch below solves
> > this.
> >
> > The other two errors come from the command loop, they are caused by
> > the fact that calling message signaled an error, and that interrupted
> > the rest of loadup.el loading. So Emacs now enters the command loop
> > with most of its support code absent.
> >
> > If the patch below solves the error in calling message, it should also
> > prevent these other 2 errors.
>
> Yes, with that patch the emacs-25 branch starts up fine — X11 mode and tty mode (including in a way-too-narrow window), normal and CANNOT_DUMP.
Thanks, pushed.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-11 19:47 ` Eli Zaretskii
2016-03-11 20:50 ` Kenneth Raeburn
2016-03-11 20:51 ` Andreas Schwab
@ 2016-03-15 18:29 ` Stefan Monnier
2016-03-15 18:44 ` Eli Zaretskii
2 siblings, 1 reply; 26+ messages in thread
From: Stefan Monnier @ 2016-03-15 18:29 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22975, Ken Raeburn
> OK, I see. So now it's crystal clear that bidi-display-reordering
> should be bound to nil until loadup finishes, otherwise we are
> playing with fire.
Actually, I think this problem goes much further. Maybe we're lucky
right now and we don't hit any other such cases, but we just shouldn't
try to do any "terminal" output until loadup is loaded.
IOW, we should work hard to minimize the difference between what happens
in the CANNOT_DUMP case and in the normal case.
More specifically I think that the "temacs -nw" case should start with
a dummy terminal and only switch to the termcap terminal after loadup
is loaded.
Stefan
^ permalink raw reply [flat|nested] 26+ messages in thread* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-15 18:29 ` Stefan Monnier
@ 2016-03-15 18:44 ` Eli Zaretskii
2016-03-15 19:31 ` Stefan Monnier
0 siblings, 1 reply; 26+ messages in thread
From: Eli Zaretskii @ 2016-03-15 18:44 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 22975, raeburn
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Ken Raeburn <raeburn@raeburn.org>, 22975@debbugs.gnu.org
> Date: Tue, 15 Mar 2016 14:29:29 -0400
>
> Actually, I think this problem goes much further. Maybe we're lucky
> right now and we don't hit any other such cases, but we just shouldn't
> try to do any "terminal" output until loadup is loaded.
Can you elaborate? Which other problems do you envision? The display
routines are all set, the only problem is with code in Lisp, or with
tables used by C that are set up by loading some Lisp.
^ permalink raw reply [flat|nested] 26+ messages in thread
* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-15 18:44 ` Eli Zaretskii
@ 2016-03-15 19:31 ` Stefan Monnier
2016-03-15 19:48 ` Eli Zaretskii
0 siblings, 1 reply; 26+ messages in thread
From: Stefan Monnier @ 2016-03-15 19:31 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22975, raeburn
>> Actually, I think this problem goes much further. Maybe we're lucky
>> right now and we don't hit any other such cases, but we just shouldn't
>> try to do any "terminal" output until loadup is loaded.
> Can you elaborate? Which other problems do you envision?
None in particular. I just think it would be safer.
Most of Emacs's code is written under the assumption that all of
loadup.el is already loaded, so we should run as little code as possible
during loadup.el itself.
Stefan
^ permalink raw reply [flat|nested] 26+ messages in thread* bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode
2016-03-15 19:31 ` Stefan Monnier
@ 2016-03-15 19:48 ` Eli Zaretskii
0 siblings, 0 replies; 26+ messages in thread
From: Eli Zaretskii @ 2016-03-15 19:48 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 22975, raeburn
> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: raeburn@raeburn.org, 22975@debbugs.gnu.org
> Date: Tue, 15 Mar 2016 15:31:30 -0400
>
> Most of Emacs's code is written under the assumption that all of
> loadup.el is already loaded, so we should run as little code as possible
> during loadup.el itself.
We do. What runs then is 'load', which announces the loaded files, and
that's all.
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2016-03-15 19:48 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-03-10 5:41 bug#22975: 25.0.92; CANNOT_DUMP build can't start in tty mode Ken Raeburn
2016-03-10 7:10 ` Eli Zaretskii
2016-03-10 7:39 ` Eli Zaretskii
2016-03-11 11:17 ` Ken Raeburn
2016-03-11 14:31 ` Eli Zaretskii
2016-03-11 19:18 ` Ken Raeburn
2016-03-11 19:47 ` Eli Zaretskii
2016-03-11 20:50 ` Kenneth Raeburn
2016-03-11 20:51 ` Andreas Schwab
2016-03-11 21:06 ` Eli Zaretskii
2016-03-12 10:01 ` Eli Zaretskii
2016-03-13 1:21 ` Ken Raeburn
2016-03-13 12:08 ` martin rudalics
2016-03-13 16:46 ` Eli Zaretskii
2016-03-13 20:09 ` martin rudalics
2016-03-13 20:31 ` Eli Zaretskii
2016-03-14 7:42 ` martin rudalics
2016-03-13 16:45 ` Eli Zaretskii
2016-03-14 7:17 ` Ken Raeburn
2016-03-14 17:41 ` Eli Zaretskii
2016-03-15 3:33 ` Ken Raeburn
2016-03-15 17:48 ` Eli Zaretskii
2016-03-15 18:29 ` Stefan Monnier
2016-03-15 18:44 ` Eli Zaretskii
2016-03-15 19:31 ` Stefan Monnier
2016-03-15 19:48 ` Eli Zaretskii
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).