* emacs crash
@ 2003-08-16 13:56 Werner LEMBERG
2003-08-18 4:52 ` Richard Stallman
0 siblings, 1 reply; 22+ messages in thread
From: Werner LEMBERG @ 2003-08-16 13:56 UTC (permalink / raw)
[This is CVS 2003-07-30]
I just got the following crash. Please tell me what I shall do.
Werner
======================================================================
Program received signal SIGSEGV, Segmentation fault.
0x081259f8 in mark_object (arg=543454268) at alloc.c:4991
4991 if (XMARKER (obj)->gcmarkbit)
#0 0x081259f8 in mark_object (arg=543454268) at alloc.c:4991
obj = 6583356
cdr_count = 0
#1 0x081255e8 in mark_object (arg=1487814016) at alloc.c:4831
size = 48
i = 0
obj = 0
cdr_count = 0
#2 0x081224b9 in mark_interval (i=0x8d8ece4, dummy=405548708) at alloc.c:1187
i = 0x2
#3 0x081710ed in traverse_intervals_noorder (tree=0x8d8ece4,
function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:207
tree = 0x8d8ece4
function = (void (*)()) 0x81224a0 <mark_interval>
arg = 405548708
#4 0x0817110e in traverse_intervals_noorder (tree=0x8d8ed00,
function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:212
tree = 0x8d8ed00
function = (void (*)()) 0x81224a0 <mark_interval>
arg = 405548708
#5 0x0817110e in traverse_intervals_noorder (tree=0x8d8ecc8,
function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:212
tree = 0x8d8ed38
function = (void (*)()) 0x81224a0 <mark_interval>
arg = 405548708
#6 0x0817110e in traverse_intervals_noorder (tree=0x8d8ee18,
function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:212
tree = 0x8d8ee18
function = (void (*)()) 0x81224a0 <mark_interval>
arg = 405548708
#7 0x0817110e in traverse_intervals_noorder (tree=0x8d8ee88,
function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:212
tree = 0x8d8ee88
function = (void (*)()) 0x81224a0 <mark_interval>
arg = 405548708
#8 0x0817110e in traverse_intervals_noorder (tree=0x8dc9684,
function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:212
tree = 0x8d8ef68
function = (void (*)()) 0x81224a0 <mark_interval>
arg = 405548708
#9 0x0817110e in traverse_intervals_noorder (tree=0x8a543e0,
function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:212
tree = 0x8d798bc
function = (void (*)()) 0x81224a0 <mark_interval>
arg = 405548708
#10 0x0817110e in traverse_intervals_noorder (tree=0x8aa91f4,
function=0x81224a0 <mark_interval>, arg=405548708) at intervals.c:212
tree = 0x8aa91f4
function = (void (*)()) 0x81224a0 <mark_interval>
arg = 405548708
#11 0x081224dd in mark_interval_tree (tree=0x8aa91f4) at alloc.c:1202
tree = 0x2
#12 0x08125bb4 in mark_buffer (buf=1219647024) at alloc.c:5098
buffer = (struct buffer *) 0x8b25630
ptr = (int *) 0x48b25630
tmp = 2
base_buffer = 2
#13 0x0812558c in mark_object (arg=1219647024) at alloc.c:4808
obj = 1219647024
cdr_count = 0
#14 0x08125a4a in mark_object (arg=677176588) at alloc.c:5008
obj = 140305676
cdr_count = 0
#15 0x0812596e in mark_object (arg=405681452) at alloc.c:4968
ptr = (struct Lisp_Symbol *) 0x82e352c
obj = 137245996
cdr_count = 0
#16 0x08125b1b in mark_object (arg=1490682944) at alloc.c:5061
ptr = (struct Lisp_Cons *) 0x8da0440
obj = 148506600
cdr_count = 0
#17 0x08125b1b in mark_object (arg=1490682952) at alloc.c:5061
ptr = (struct Lisp_Cons *) 0x8da0448
obj = 148506600
cdr_count = 0
#18 0x08125dbe in mark_buffer (buf=1218972696) at alloc.c:5150
buffer = (struct buffer *) 0x8a80c18
ptr = (int *) 0x8a80d00
tmp = 2
base_buffer = 2
#19 0x0812558c in mark_object (arg=1218972696) at alloc.c:4808
obj = 1218972696
cdr_count = 0
#20 0x08125a4a in mark_object (arg=681782748) at alloc.c:5008
obj = 144911836
cdr_count = 0
#21 0x0812596e in mark_object (arg=405706996) at alloc.c:4968
ptr = (struct Lisp_Symbol *) 0x82f5b0c
obj = 137321228
cdr_count = 0
...
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs crash
2003-08-16 13:56 Werner LEMBERG
@ 2003-08-18 4:52 ` Richard Stallman
0 siblings, 0 replies; 22+ messages in thread
From: Richard Stallman @ 2003-08-18 4:52 UTC (permalink / raw)
Cc: emacs-devel
0x081259f8 in mark_object (arg=543454268) at alloc.c:4991
4991 if (XMARKER (obj)->gcmarkbit)
#0 0x081259f8 in mark_object (arg=543454268) at alloc.c:4991
obj = 6583356
cdr_count = 0
#1 0x081255e8 in mark_object (arg=1487814016) at alloc.c:4831
size = 48
i = 0
obj = 0
cdr_count = 0
You need to look at the objects being marked in these calls, and the
data structure they belong to, and figure out what's invalid
about the data structure.
That is the first step. After that step, there will probably be more
debugging to do, but we can't guess now what it will be.
^ permalink raw reply [flat|nested] 22+ messages in thread
* emacs crash
@ 2003-10-08 12:42 Werner LEMBERG
0 siblings, 0 replies; 22+ messages in thread
From: Werner LEMBERG @ 2003-10-08 12:42 UTC (permalink / raw)
[CVS 2003-09-29]
Below is a backtrace of an Emacs crash which hasn't happened during
garbage collection. I still have this Emacs process so I can execute
your commands if necessary. IIRC, the segfault happened while
scrolling new Email (with various character sets) in Mew.
Of the variables shown under #0, `faces' and `char2b' are invalid
pointers (besides `s' and `first_s', of course).
Werner
======================================================================
Program received signal SIGSEGV, Segmentation fault.
0x08078bd3 in draw_glyphs (w=0x8f5e638, x=157, row=0x8e44590, area=TEXT_AREA,
start=0, end=62, hl=DRAW_NORMAL_TEXT, overlaps_p=0) at xdisp.c:17461
17461 BUILD_GLYPH_STRINGS (i, end, head, tail, hl, x, last_x);
(gdb) bt full
#0 0x08078bd3 in draw_glyphs (w=0x8f5e638, x=157, row=0x8e44590,
area=TEXT_AREA, start=0, end=62, hl=DRAW_NORMAL_TEXT, overlaps_p=0)
at xdisp.c:17461
c = 2747
this_face_id = 150339144
cmp_id = 2747
face_id = 150339144
base_face = (struct face *) 0x8ad25e0
char2b = (XChar2b *) 0x3fffe154
cmp = (struct composition *) 0x8f5fe80
glyph_len = 1073741826
faces = (struct face **) 0x3fffe144
first_s = (struct glyph_string *) 0x0
n = 0
head = (struct glyph_string *) 0xbfffe664
tail = (struct glyph_string *) 0xbfffe1d4
s = (struct glyph_string *) 0xabb
last_x = 973
x_reached = 149177744
i = 12
j = -1073748396
f = (struct frame *) 0x8640de8
#1 0x0807d00e in x_write_glyphs (start=0x8ff58f0, len=62) at xdisp.c:18503
start = (struct glyph *) 0x8f5fe48
x = 149177744
#2 0x08053fa5 in update_text_area (w=0x8f5e638, vpos=0) at dispnew.c:4270
current_row = (struct glyph_row *) 0x8f589f8
desired_row = (struct glyph_row *) 0x8e44590
changed_p = 0
#3 0x080543e6 in update_window_line (w=0x8f5e638, vpos=0,
mouse_face_overwritten_p=0xbfffe938) at dispnew.c:4494
w = (struct window *) 0x8f5e638
mouse_face_overwritten_p = (int *) 0x0
current_row = (struct glyph_row *) 0x8f589f8
desired_row = (struct glyph_row *) 0x8e44590
changed_p = 0
#4 0x08053d2b in update_window (w=0x8f5e638, force_p=0) at dispnew.c:4150
vpos = 0
i = 150339144
end = (struct glyph_row *) 0x8e45980
mode_line_row = (struct glyph_row *) 0x8f5fe80
header_line_row = (struct glyph_row *) 0x0
changed_p = 1
mouse_face_overwritten_p = 0
row = (struct glyph_row *) 0x8e44590
yb = 504
n_updated = 1
desired_matrix = (struct glyph_matrix *) 0x8c2abe0
paused_p = 0
preempt_count = 9
#5 0x08053793 in update_window_tree (w=0x8f94f40, force_p=0) at dispnew.c:3885
w = (struct window *) 0x8f5e638
force_p = 0
paused_p = 0
#6 0x08053778 in update_window_tree (w=0x8f97a88, force_p=0) at dispnew.c:3883
w = (struct window *) 0x8f97a88
force_p = 0
paused_p = 0
#7 0x08053691 in update_frame (f=0x8640de8, force_p=0, inhibit_hairy_id_p=0)
at dispnew.c:3822
f = (struct frame *) 0x8640de8
inhibit_hairy_id_p = 0
paused_p = 140818216
root_window = (struct window *) 0x8f97a88
#8 0x0806cdba in redisplay_internal (preserve_echo_area=0) at xdisp.c:10050
f = (struct frame *) 0x8640de8
tail = 150339144
frame = 150339144
i = 1
updated = (struct frame **) 0xbfffe9f4
n = 0
size = 50
w = (struct window *) 0x8f94f40
f = (struct frame *) 0x8f5fe80
pause = 0
must_finish = 1
tlbufpos = {charpos = 64537, bytepos = 64644}
tlendpos = {charpos = 6428, bytepos = 6508}
number_of_visible_frames = 1
count = 2
polling_stopped_here = 1
consider_all_windows_p = 1
#9 0x0806bcd0 in redisplay () at xdisp.c:9448
No locals.
#10 0x080e1375 in read_char (commandflag=1, nmaps=2, maps=0xbffff0f4,
prev_event=675054316, used_mouse_menu=0xbffff148) at keyboard.c:2495
c = 675054316
count = 0
local_getcjmp = {{__jmpbuf = {0, 0, 138441496, -1471787984, 675428364,
135432523}, __mask_was_saved = 138441496, __saved_mask = {__val = {
3221221484, 3221221484, 135432701, 675428364, 675054316, 675054316, 0,
1212183320, 675428364, 675428364, 135457263, 140715040, 2288198688,
3221221532, 135432844, 675428364, 1212183320, 64537, 135748393, 2, 0,
516296, 675054316, 3221221332, 64537, 3221221612, 135195085,
675404660, 0, 0, 135743368, 2}}}}
save_jump = {{__jmpbuf = {135740232, -1460667568, 675147572, 1,
-1073745988, 135747853}, __mask_was_saved = 64536, __saved_mask = {
__val = {3221221308, 135747862, 2834299728, 675147572, 0, 140715040, 0,
1, 3221221532, 135457649, 64536, 675147572, 2288198688, 135457649,
1215067860, 675260524, 2288198688, 135437987, 1215067860, 141495344,
142050320, 0, 1, 19, 3221221148, 135504025, 2826020352, 0, 8192, 0,
138441496, 2823179312}}}}
key_already_recorded = 0
tem = 0
save = 0
previous_echo_area_message = 675054316
also_record = 675054316
reread = 0
gcpro1 = {next = 0x486c76d4, var = 0xffffffff, nvars = 140715040}
gcpro2 = {next = 0x283c82ec, var = 0xbfffef7c, nvars = -1073746032}
last_idle_start = {tv_sec = 675054316, tv_usec = 64536}
polling_stopped_here = 0
#11 0x080e881f in read_key_sequence (keybuf=0xbffff254, bufsize=30,
prompt=675054316, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at keyboard.c:8825
key = 209
used_mouse_menu = 0
echo_local_start = 0
last_real_key_start = 0
keys_local_start = 0
local_first_binding = 0
from_string = 675054316
count = 2
t = 0
echo_start = 0
keys_start = 0
nmaps = 2
nmaps_allocated = 2
defs = (int *) 0xbffff0e4
submaps = (int *) 0xbffff0f4
orig_local_map = -1469255984
orig_keymap = 675054316
localized_local_map = 0
first_binding = 0
first_unbound = 31
mock_input = 0
fkey = {map = -1472400872, parent = -1472400872, start = 0, end = 0}
keytran = {map = -1471723376, parent = -1471723376, start = 0, end = 0}
delayed_switch_frame = 675054316
original_uppercase = 0
original_uppercase_position = -1
starting_buffer = (struct buffer *) 0x8632420
fake_prefixed_keys = 675054316
gcpro1 = {next = 0x0, var = 0x0, nvars = -1073745492}
#12 0x080df764 in command_loop_1 () at keyboard.c:1504
cmd = 2
lose = 2
nonundocount = 0
keybuf = {32, 98, -1073745220, 135131396, -1459750176, -1073745272,
-1073745220, 135131319, 0, 1, -1073743836, 1077983524, 135701888,
-1073744896, 17, 1076885774, 177478308, 1073775649, -1073745104, 32,
-1073745020, 0, -1073745312, -1073745452, 0, 1073741824, -1073744964,
135494457, -1073745148, -1073744768}
i = 2
no_direct = 0
prev_modiff = 6467
prev_buffer = (struct buffer *) 0x8632420
was_locked = 0
already_adjusted = 0
#13 0x08137b8d in internal_condition_case (bfun=0x80df450 <command_loop_1>,
handlers=675148004, hfun=0x80df030 <cmd_error>) at eval.c:1333
val = 150339144
c = {tag = 675054316, val = 675054316, next = 0xbffff404, gcpro = 0x0,
jmp = {{__jmpbuf = {0, 1, -1073743836, -1073744964, -1073745212, 135494457},
__mask_was_saved = 0, __saved_mask = {__val = {3221222348, 3221222100,
135494457, 0, 134530924, 335544320, 1076991992, 1076844252,
1074843024, 0 <repeats 16 times>, 3221222356, 1073787006,
1073827532, 1078006536, 1, 0, 0}}}}, backlist = 0x0,
handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2,
poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0}
h = {handler = 675148004, var = 675054316, chosen_clause = 675054364,
tag = 0xbffff2f4, next = 0x0}
#14 0x080df2fe in command_loop_2 () at keyboard.c:1292
val = 0
#15 0x081376f5 in internal_catch (tag=675109268,
func=0x80df2e0 <command_loop_2>, arg=675054316) at eval.c:1094
tag = 150339144
c = {tag = 675109268, val = 675054316, next = 0x0, gcpro = 0x0, jmp = {
{__jmpbuf = {0, 1, -1073743836, -1073744692, -1073744924, 135493346},
__mask_was_saved = 0, __saved_mask = {__val = {3221222620, 3221222388,
135493346, 0, 3221222528, 3221222539, 0, 1077983524, 808465724,
3221222428, 1077248756, 5, 1077986688, 138389272, 138411460,
1212131096, 3221222204, 138209992, 675054316, 3221222588, 135434098,
675282372, 1212131096, 675054316, 138231648, 138411460, 675282372,
1212131096, 0, 138411460, 675282372, 137907392}}}}, backlist = 0x0,
handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2,
poll_suppress_count = 1, interrupt_input_blocked = 0, byte_stack = 0x0}
#16 0x080df2a3 in command_loop () at keyboard.c:1271
No locals.
#17 0x080deda4 in recursive_edit_1 () at keyboard.c:987
count = 1
val = 0
#18 0x080deee1 in Frecursive_edit () at keyboard.c:1043
count = 0
buffer = 0
#19 0x080ddc35 in main (argc=1, argv=0xbffff824) at emacs.c:1666
dummy = 0
stack_bottom_variable = 0 '\0'
skip_args = 0
rlim = {rlim_cur = 8388608, rlim_max = 18446744073709551615}
no_loadup = 0
junk = 0x0
#20 0x403087ee in __libc_start_main () from /lib/libc.so.6
^ permalink raw reply [flat|nested] 22+ messages in thread
* emacs crash
@ 2004-11-03 9:55 B. Anyos
2004-11-03 10:28 ` Jason Rumney
0 siblings, 1 reply; 22+ messages in thread
From: B. Anyos @ 2004-11-03 9:55 UTC (permalink / raw)
Hi,
I checked out the latest version form CVS.
I cleaned my version and compiled it from sratch.
Even tried "nmake bootstrap".
When I try to exeucte emacs it crashed with a message box:
==================
Emacs Abort Dialog
==================
"A fatal error occured!"
"Select Abort to exit, Retry to debug, Ignore to continue"
Any idea how can I fix this.
Bela
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs crash
2004-11-03 9:55 emacs crash B. Anyos
@ 2004-11-03 10:28 ` Jason Rumney
2004-11-03 10:50 ` B. Anyos
2004-11-03 11:06 ` Dhruva Krishnamurthy
0 siblings, 2 replies; 22+ messages in thread
From: Jason Rumney @ 2004-11-03 10:28 UTC (permalink / raw)
Cc: emacs-devel
B. Anyos wrote:
> When I try to exeucte emacs it crashed with a message box:
>
> ==================
> Emacs Abort Dialog
> ==================
> "A fatal error occured!"
> "Select Abort to exit, Retry to debug, Ignore to continue"
>
Did you try pressing Retry? If you have a just-in-time debugger
installed, that should show where the program is crashing.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs crash
2004-11-03 10:28 ` Jason Rumney
@ 2004-11-03 10:50 ` B. Anyos
2004-11-03 11:21 ` Jason Rumney
2004-11-03 11:06 ` Dhruva Krishnamurthy
1 sibling, 1 reply; 22+ messages in thread
From: B. Anyos @ 2004-11-03 10:50 UTC (permalink / raw)
Cc: Jason Rumney
Jason Rumney said the following on 11/3/2004 11:28 AM:
> B. Anyos wrote:
>
>> When I try to exeucte emacs it crashed with a message box:
>>
>> ==================
>> Emacs Abort Dialog
>> ==================
>> "A fatal error occured!"
>> "Select Abort to exit, Retry to debug, Ignore to continue"
>>
> Did you try pressing Retry? If you have a just-in-time debugger
> installed, that should show where the program is crashing.
>
Sure in the meantime I did. It crashed in emacs\src\eval.c
at line 409.
DEFUN ("progn", Fprogn, Sprogn, 0, UNEVALLED, 0,
doc: /* Eval BODY forms sequentially and return value of last one.
usage: (progn BODY ...) */)
(args)
Lisp_Object args;
{
register Lisp_Object val = Qnil;
struct gcpro gcpro1;
GCPRO1 (args);
while (CONSP (args))
{
val = Feval (XCAR (args));
-> args = XCDR (args);
}
UNGCPRO;
return val;
}
Here is the stack trace:
NTDLL! 77f75a58()
Fprogn(int -1592181732) line 409
unbind_to(int 656, int 556594176) line 3124
Fbyte_code(int 18430916, int -2129052740, int 7) line 716 + 17 bytes
funcall_lambda(int -2129052976, int 3, int * 0x0082f188) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f188) line 2814 + 12 bytes
Fbyte_code(int 19015816, int -2128467840, int 4) line 688
funcall_lambda(int -2128467916, int 1, int * 0x0082f244) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f244) line 2814 + 12 bytes
Fbyte_code(int 19018312, int -2128465344, int 5) line 688
funcall_lambda(int -2128465448, int 2, int * 0x0082f304) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f304) line 2814 + 12 bytes
call2(int 556627832, int 1633770048, int -2127346688) line 2569 + 11 bytes
tty_lookup_color() line 1320
tty_defined_color() line 1385 + 18 bytes
load_face_colors(frame * 0x01334400, face * 0x015ce500, int * 0x61724310) line 1680 + 45 bytes
realize_x_face(face_cache * 0x01334400, int * 0x0082f3f8, int 0, face * 0x00000000) line 7144
realize_face(face_cache * 0x01710080, int * 0x0082f3f8, int 0, face * 0x00000000, int 0) line 7040 + 15 bytes
realize_default_face(frame * 0x812ca600) line 6967 + 17 bytes
realize_basic_faces(frame * 0x01334400) line 6834 + 9 bytes
Fdisplay_supports_face_attributes_p(int -1590125944, int -2127346688) line 6132 + 6 bytes
Ffuncall(int -2147483648, int * 0x0082f508) line 2761 + 8 bytes
Fbyte_code(int 18628360, int -2128855296, int 5) line 688
funcall_lambda(int -2128855556, int 2, int * 0x0082f5c8) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f5c8) line 2814 + 12 bytes
Fbyte_code(int 18628728, int -2128854928, int 4) line 688
funcall_lambda(int -2128855088, int 2, int * 0x0082f684) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f684) line 2814 + 12 bytes
Fbyte_code(int 18629200, int -2128854456, int 6) line 688
funcall_lambda(int -2128854656, int 3, int * 0x0082f748) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f748) line 2814 + 12 bytes
Fbyte_code(int 18634476, int -2128849180, int 5) line 688
Feval(int 8583088) line 2120
Fcondition_case(int -1589005424) line 1314 + 62 bytes
Fbyte_code(int 18634264, int -2128849392, int 9) line 864 + 17 bytes
funcall_lambda(int -2128849612, int 1, int * 0x0082f980) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
call1(int 556794192, int -2127346688) line 2547 + 11 bytes
Fx_create_frame(int 0) line 4355
Ffuncall(int -2147483648, int * 0x0082fa0c) line 2758
Fbyte_code(int 18633764, int -2128849892, int 5) line 688
funcall_lambda(int -2128850016, int 1, int * 0x0082fac4) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fac4) line 2814 + 12 bytes
Fbyte_code(int 19004120, int -2128479536, int 3) line 688
funcall_lambda(int -2128479620, int 1, int * 0x0082fb7c) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fb7c) line 2814 + 12 bytes
Fbyte_code(int 19000176, int -2128483480, int 4) line 688
funcall_lambda(int -2128483612, int 0, int * 0x0082fc38) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fc38) line 2814 + 12 bytes
Fbyte_code(int 19140348, int -2128343308, int 6) line 688
funcall_lambda(int -2128344604, int 0, int * 0x0082fcfc) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fcfc) line 2814 + 12 bytes
Fbyte_code(int 19134352, int -2128349304, int 7) line 688
funcall_lambda(int -2128349488, int 0, int * 0x0082fd8c) line 2946 + 17 bytes
apply_lambda(int -2128349488, int 556594176, int 1) line 2869
Feval(int -2147483648) line 2170 + 11 bytes
top_level_2() line 1317 + 11 bytes
internal_condition_case(int (void)* 0x0100e695 top_level_2(void), int 556679768, int (void)* 0x0100e3fd cmd_error(void)) line 1368
top_level_1() line 1326 + 21 bytes
internal_catch(int 556676056, int (void)* 0x0100e6a2 top_level_1(void), int 556594176) line 1128 + 6 bytes
command_loop() line 1288
recursive_edit_1() line 981 + 5 bytes
Frecursive_edit() line 1043
main() line 1738 + 5 bytes
EMACS! mainCRTStartup + 180 bytes
KERNEL32! 77e8141a()
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs crash
2004-11-03 10:28 ` Jason Rumney
2004-11-03 10:50 ` B. Anyos
@ 2004-11-03 11:06 ` Dhruva Krishnamurthy
2004-11-03 14:09 ` CHENG Gao
1 sibling, 1 reply; 22+ messages in thread
From: Dhruva Krishnamurthy @ 2004-11-03 11:06 UTC (permalink / raw)
Cc: B. Anyos, emacs-devel
Hello,
I had the same results on my XP box. Here goes the stack trace for
(runemacs -q):
NTDLL! 77f767cd()
Fprogn(int -1592177612) line 409
unbind_to(int 656, int 556578816) line 3124
Fbyte_code(int 18435036, int -2129048620, int 7) line 716 + 17 bytes
funcall_lambda(int -2129048856, int 3, int * 0x0082f188) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f188) line 2814 + 12 bytes
Fbyte_code(int 19019936, int -2128463720, int 4) line 688
funcall_lambda(int -2128463796, int 1, int * 0x0082f244) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f244) line 2814 + 12 bytes
Fbyte_code(int 19022432, int -2128461224, int 5) line 688
funcall_lambda(int -2128461328, int 2, int * 0x0082f304) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f304) line 2814 + 12 bytes
call2(int 556641144, int 1633580288, int -2127505408) line 2569 + 11 bytes
tty_lookup_color() line 1320
tty_defined_color() line 1385 + 18 bytes
load_face_colors(frame * 0x0130d800, face * 0x01541000, int *
0x61724310) line 1680 + 45 bytes
realize_x_face(face_cache * 0x0130d800, int * 0x0082f3f8, int 0, face
* 0x00000000) line 7144
realize_face(face_cache * 0x0170e540, int * 0x0082f3f8, int 0, face *
0x00000000, int 0) line 7040 + 15 bytes
realize_default_face(frame * 0x812cc800) line 6967 + 17 bytes
realize_basic_faces(frame * 0x0130d800) line 6834 + 9 bytes
Fdisplay_supports_face_attributes_p(int -1590109480, int -2127505408)
line 6132 + 6 bytes
Ffuncall(int -2147483648, int * 0x0082f508) line 2761 + 8 bytes
Fbyte_code(int 18632480, int -2128851176, int 5) line 688
funcall_lambda(int -2128851436, int 2, int * 0x0082f5c8) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f5c8) line 2814 + 12 bytes
Fbyte_code(int 18632848, int -2128850808, int 4) line 688
funcall_lambda(int -2128850968, int 2, int * 0x0082f684) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f684) line 2814 + 12 bytes
Fbyte_code(int 18633320, int -2128850336, int 6) line 688
funcall_lambda(int -2128850536, int 3, int * 0x0082f748) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f748) line 2814 + 12 bytes
Fbyte_code(int 18638596, int -2128845060, int 5) line 688
Feval(int 8583088) line 2120
Fcondition_case(int -1588988960) line 1314 + 62 bytes
Fbyte_code(int 18638384, int -2128845272, int 9) line 864 + 17 bytes
funcall_lambda(int -2128845492, int 1, int * 0x0082f980) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
call1(int 556796240, int -2127505408) line 2547 + 11 bytes
Fx_create_frame(int 0) line 4355
Ffuncall(int -2147483648, int * 0x0082fa0c) line 2758
Fbyte_code(int 18637884, int -2128845772, int 5) line 688
funcall_lambda(int -2128845896, int 1, int * 0x0082fac4) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fac4) line 2814 + 12 bytes
Fbyte_code(int 19008240, int -2128475416, int 3) line 688
funcall_lambda(int -2128475500, int 1, int * 0x0082fb7c) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fb7c) line 2814 + 12 bytes
Fbyte_code(int 19004296, int -2128479360, int 4) line 688
funcall_lambda(int -2128479492, int 0, int * 0x0082fc38) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fc38) line 2814 + 12 bytes
Fbyte_code(int 19144468, int -2128339188, int 6) line 688
funcall_lambda(int -2128340484, int 0, int * 0x0082fcfc) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082fcfc) line 2814 + 12 bytes
Fbyte_code(int 19138472, int -2128345184, int 7) line 688
funcall_lambda(int -2128345368, int 0, int * 0x0082fd8c) line 2946 + 17 bytes
apply_lambda(int -2128345368, int 556578816, int 1) line 2869
Feval(int -2147483648) line 2170 + 11 bytes
top_level_2() line 1317 + 11 bytes
internal_condition_case(int (void)* 0x0100e695 top_level_2(void), int
556684888, int (void)* 0x0100e3fd cmd_error(void)) line 1368
top_level_1() line 1326 + 21 bytes
internal_catch(int 556681176, int (void)* 0x0100e6a2
top_level_1(void), int 556578816) line 1128 + 6 bytes
command_loop() line 1288
recursive_edit_1() line 981 + 5 bytes
Frecursive_edit() line 1043
main() line 1738 + 5 bytes
EMACS! mainCRTStartup + 180 bytes
KERNEL32! 77e814c7()
On Wed, 03 Nov 2004 10:28:43 +0000, Jason Rumney <jasonr@gnu.org> wrote:
> B. Anyos wrote:
>
> > When I try to exeucte emacs it crashed with a message box:
> >
> > ==================
> > Emacs Abort Dialog
> > ==================
> > "A fatal error occured!"
> > "Select Abort to exit, Retry to debug, Ignore to continue"
> >
> Did you try pressing Retry? If you have a just-in-time debugger
> installed, that should show where the program is crashing.
-dhruva
--
Proud FSF member: #1935
http://schemer.fateback.com/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs crash
2004-11-03 10:50 ` B. Anyos
@ 2004-11-03 11:21 ` Jason Rumney
2004-11-03 11:29 ` Dhruva Krishnamurthy
2004-11-03 12:02 ` B. Anyos
0 siblings, 2 replies; 22+ messages in thread
From: Jason Rumney @ 2004-11-03 11:21 UTC (permalink / raw)
Cc: emacs-devel
B. Anyos wrote:
> tty_lookup_color() line 1320
> tty_defined_color() line 1385 + 18 bytes
This looks suspicious. I don't think tty_lookup_color() should be called
if you are not starting Emacs with -nw.
My guess is that something is trying to define a face before the initial
frame is created.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs crash
2004-11-03 11:21 ` Jason Rumney
@ 2004-11-03 11:29 ` Dhruva Krishnamurthy
2004-11-03 12:02 ` B. Anyos
1 sibling, 0 replies; 22+ messages in thread
From: Dhruva Krishnamurthy @ 2004-11-03 11:29 UTC (permalink / raw)
Cc: B. Anyos, emacs-devel
On Wed, 03 Nov 2004 11:21:38 +0000, Jason Rumney <jasonr@gnu.org> wrote:
> B. Anyos wrote:
>
> > tty_lookup_color() line 1320
> > tty_defined_color() line 1385 + 18 bytes
>
> This looks suspicious. I don't think tty_lookup_color() should be called
> if you are not starting Emacs with -nw.
>
> My guess is that something is trying to define a face before the initial
> frame is created.
BTW, emacs -q -nw works!
--
Proud FSF member: #1935
http://schemer.fateback.com/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs crash
2004-11-03 11:21 ` Jason Rumney
2004-11-03 11:29 ` Dhruva Krishnamurthy
@ 2004-11-03 12:02 ` B. Anyos
1 sibling, 0 replies; 22+ messages in thread
From: B. Anyos @ 2004-11-03 12:02 UTC (permalink / raw)
Cc: Jason Rumney
Jason Rumney said the following on 11/3/2004 12:21 PM:
> B. Anyos wrote:
>
>> tty_lookup_color() line 1320
>> tty_defined_color() line 1385 + 18 bytes
>
>
> This looks suspicious. I don't think tty_lookup_color() should be called
> if you are not starting Emacs with -nw.
>
> My guess is that something is trying to define a face before the initial
> frame is created.
>
>
>
It is interesting, though because it's been working recently. Only today I pulled
the latest sources and then it crashed.
BTW, 'emacs -nw' works fine. (Note that -q is omitted intentionally)
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs crash
2004-11-03 11:06 ` Dhruva Krishnamurthy
@ 2004-11-03 14:09 ` CHENG Gao
2004-11-03 15:02 ` B. Anyos
2004-11-04 9:51 ` Richard Stallman
0 siblings, 2 replies; 22+ messages in thread
From: CHENG Gao @ 2004-11-03 14:09 UTC (permalink / raw)
I think RMS' latest commit to eval.c caused this.
,----
| CVSROOT: /cvsroot/emacs
| Module name: emacs
| Branch:
| Changes by: Richard M. Stallman <rms@gnu.org> 04/11/02 08:59:26
|
| Modified files:
| src : eval.c
|
| Log message:
| (Fcall_interactive_p): New function.
| (interactive_p): Don't test INTERACTIVE here.
| (Finteractive_p): Doc fix.
|
| (Feval): Abort if INPUT_BLOCKED_P.
|
| CVSWeb URLs:
| http://savannah.gnu.org/cgi-bin/viewcvs/emacs/emacs/src/eval.c.diff?tr1=1.221&tr2=1.222&r1=text&r2=text
`----
I have a temp solution:
open src/eval.c, go to line 1999, and change:
if (handling_signal || INPUT_BLOCKED_P)
to
if (handling_signal)
then rebuild Emacs.
Maybe it's only a workaround, not a real solution.
HTH,
--
花开花谢春不管，拂意事休对人言
水暖水寒鱼自知，会心处还期独赏
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs crash
2004-11-03 14:09 ` CHENG Gao
@ 2004-11-03 15:02 ` B. Anyos
2004-11-04 9:51 ` Richard Stallman
2004-11-04 9:51 ` Richard Stallman
1 sibling, 1 reply; 22+ messages in thread
From: B. Anyos @ 2004-11-03 15:02 UTC (permalink / raw)
Cc: CHENG Gao
Hi,
Thanks for the tip.
It worked for me, too.
Bela
CHENG Gao said the following on 11/3/2004 15:09 PM:
> I think RMS' latest commit to eval.c caused this.
>
> ,----
> | CVSROOT: /cvsroot/emacs
> | Module name: emacs
> | Branch:
> | Changes by: Richard M. Stallman <rms@gnu.org> 04/11/02 08:59:26
> |
> | Modified files:
> | src : eval.c
> |
> | Log message:
> | (Fcall_interactive_p): New function.
> | (interactive_p): Don't test INTERACTIVE here.
> | (Finteractive_p): Doc fix.
> |
> | (Feval): Abort if INPUT_BLOCKED_P.
> |
> | CVSWeb URLs:
> | http://savannah.gnu.org/cgi-bin/viewcvs/emacs/emacs/src/eval.c.diff?tr1=1.221&tr2=1.222&r1=text&r2=text
> `----
>
> I have a temp solution:
> open src/eval.c, go to line 1999, and change:
>
> if (handling_signal || INPUT_BLOCKED_P)
>
> to
>
> if (handling_signal)
>
> then rebuild Emacs.
>
> Maybe it's only a workaround, not a real solution.
>
> HTH,
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs crash
2004-11-03 14:09 ` CHENG Gao
2004-11-03 15:02 ` B. Anyos
@ 2004-11-04 9:51 ` Richard Stallman
1 sibling, 0 replies; 22+ messages in thread
From: Richard Stallman @ 2004-11-04 9:51 UTC (permalink / raw)
Cc: emacs-devel
If the crash is coming from my recent debugging check in eval.c,
and was not fixed by Jan's recent changes, then it is due to
a bug that is as yet unknown.
When a debugging assertion finds a problem, please do NOT suggest
removing the debugging assertion as a "workaround". That is not
constructive; in fact, it is likely to interfere with fixing the real
bug.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs crash
2004-11-03 15:02 ` B. Anyos
@ 2004-11-04 9:51 ` Richard Stallman
2004-11-04 10:31 ` Jason Rumney
0 siblings, 1 reply; 22+ messages in thread
From: Richard Stallman @ 2004-11-04 9:51 UTC (permalink / raw)
Cc: chenggao, emacs-devel
Thanks for the tip.
It worked for me, too.
This may have "worked" in the sense of making the crash stop for you,
but it did not "work" for helping us to fix the bug. We need more
information to do that.
For instance, there is something really strange here:
funcall_lambda(int -2128849612, int 1, int * 0x0082f980) line 2946 + 17 bytes
Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
call1(int 556794192, int -2127346688) line 2547 + 11 bytes
Fx_create_frame(int 0) line 4355
There is no call to Fx_create_frame in line 4355; in fact, line 4355
is far after the end of Fx_create_frame. What's going on? I need to
see where the call actually came from, and whether it was within
BLOCK_INPUT.
Can you examine the value 556794192 with xtype and see what sort of
Lisp object it is? If it is a symbol, use xsymbol to see what its
name is. See etc/DEBUG for more details on how to use these commands.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs crash
2004-11-04 9:51 ` Richard Stallman
@ 2004-11-04 10:31 ` Jason Rumney
2004-11-04 12:52 ` B. Anyos
` (2 more replies)
0 siblings, 3 replies; 22+ messages in thread
From: Jason Rumney @ 2004-11-04 10:31 UTC (permalink / raw)
Cc: B. Anyos, emacs-devel, chenggao
Richard Stallman wrote:
>For instance, there is something really strange here:
>
> funcall_lambda(int -2128849612, int 1, int * 0x0082f980) line 2946 + 17 bytes
> Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
> call1(int 556794192, int -2127346688) line 2547 + 11 bytes
> Fx_create_frame(int 0) line 4355
>
>There is no call to Fx_create_frame in line 4355; in fact, line 4355
>is far after the end of Fx_create_frame. What's going on?
>
I think the user is on Windows, so that would be line 4355 of w32fns.c,
which is in Fx_create_frame.
My line numbers are slightly out, but I suspect this line (4350 in my
version):
/* Set up faces after all frame parameters are known. This call
also merges in face attributes specified for new frames. If we
don't do this, the `menu' face for instance won't have the right
colors, and the menu bar won't appear in the specified colors for
new frames. */
call1 (Qface_set_after_frame_default, frame);
It appears to be outside the BLOCK_INPUT blocks within x_create_frame.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs crash
2004-11-04 10:31 ` Jason Rumney
@ 2004-11-04 12:52 ` B. Anyos
2004-11-04 13:08 ` Dhruva Krishnamurthy
2004-11-04 15:48 ` B. Anyos
2004-11-04 17:05 ` Jan D.
2 siblings, 1 reply; 22+ messages in thread
From: B. Anyos @ 2004-11-04 12:52 UTC (permalink / raw)
Cc: chenggao, rms, emacs-devel
It is true, I'm running emacs on Windows. So stacktrace is stopped right in
the middle of Fx_create_frame, though it seems it is over BLOCK_INPUT.
(file w32fns.c)
Anyway I tried to do what you asked for. Here's what I could figure out.
debug_print(args[0]):
face-set-after-frame-default
(struct Lisp_String *)(0xfffffff & ((struct Lisp_Symbol *) (0xfffffff & args[0]))->xname):
size 28
size_byte -1
intervals 0x00000000
data 0x01185dd0 "face-set-after-frame-default"
I hope this helps.
Unfortunately those nice commands listed in .gdbinit do not exist on MS Windows.
Any alternatives to help debugging on Windows ?
Jason Rumney said the following on 11/4/2004 11:31 AM:
> Richard Stallman wrote:
>
>> For instance, there is something really strange here:
>>
>> funcall_lambda(int -2128849612, int 1, int * 0x0082f980) line 2946
>> + 17 bytes
>> Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
>> call1(int 556794192, int -2127346688) line 2547 + 11 bytes
>> Fx_create_frame(int 0) line 4355
>>
>> There is no call to Fx_create_frame in line 4355; in fact, line 4355
>> is far after the end of Fx_create_frame. What's going on?
>>
> I think the user is on Windows, so that would be line 4355 of w32fns.c,
> which is in Fx_create_frame.
>
> My line numbers are slightly out, but I suspect this line (4350 in my
> version):
>
> /* Set up faces after all frame parameters are known. This call
> also merges in face attributes specified for new frames. If we
> don't do this, the `menu' face for instance won't have the right
> colors, and the menu bar won't appear in the specified colors for
> new frames. */
> call1 (Qface_set_after_frame_default, frame);
>
>
> It appears to be outside the BLOCK_INPUT blocks within x_create_frame.
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs crash
2004-11-04 12:52 ` B. Anyos
@ 2004-11-04 13:08 ` Dhruva Krishnamurthy
2004-11-05 8:38 ` Cheng Gao
0 siblings, 1 reply; 22+ messages in thread
From: Dhruva Krishnamurthy @ 2004-11-04 13:08 UTC (permalink / raw)
Cc: Emacs-Devel
Hello,
Now, this problem has encroached emacs-unicode-2 branch too. With the
automatic sync, which IMO has happened today, we have the same problem
(which leaves me with no working emacs).
-dhruva
On Thu, 04 Nov 2004 13:52:04 +0100, B. Anyos <banyos@freemail.hu> wrote:
> It is true, I'm running emacs on Windows. So stacktrace is stopped right in
> the middle of Fx_create_frame, though it seems it is over BLOCK_INPUT.
> (file w32fns.c)
>
> Anyway I tried to do what you asked for. Here's what I could figure out.
>
> debug_print(args[0]):
> face-set-after-frame-default
>
> (struct Lisp_String *)(0xfffffff & ((struct Lisp_Symbol *) (0xfffffff & args[0]))->xname):
> size 28
> size_byte -1
> intervals 0x00000000
> data 0x01185dd0 "face-set-after-frame-default"
>
> I hope this helps.
>
> Unfortunately those nice commands listed in .gdbinit do not exist on MS Windows.
> Any alternatives to help debugging on Windows ?
>
> Jason Rumney said the following on 11/4/2004 11:31 AM:
> > Richard Stallman wrote:
> >
> >> For instance, there is something really strange here:
> >>
> >> funcall_lambda(int -2128849612, int 1, int * 0x0082f980) line 2946
> >> + 17 bytes
> >> Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
> >> call1(int 556794192, int -2127346688) line 2547 + 11 bytes
> >> Fx_create_frame(int 0) line 4355
> >>
> >> There is no call to Fx_create_frame in line 4355; in fact, line 4355
> >> is far after the end of Fx_create_frame. What's going on?
> >>
> > I think the user is on Windows, so that would be line 4355 of w32fns.c,
> > which is in Fx_create_frame.
> >
> > My line numbers are slightly out, but I suspect this line (4350 in my
> > version):
> >
> > /* Set up faces after all frame parameters are known. This call
> > also merges in face attributes specified for new frames. If we
> > don't do this, the `menu' face for instance won't have the right
> > colors, and the menu bar won't appear in the specified colors for
> > new frames. */
> > call1 (Qface_set_after_frame_default, frame);
> >
> >
> > It appears to be outside the BLOCK_INPUT blocks within x_create_frame.
> >
> >
> >
> > _______________________________________________
> > Emacs-devel mailing list
> > Emacs-devel@gnu.org
> > http://lists.gnu.org/mailman/listinfo/emacs-devel
> >
> >
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>
--
Proud FSF member: #1935
http://schemer.fateback.com/
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs crash
2004-11-04 10:31 ` Jason Rumney
2004-11-04 12:52 ` B. Anyos
@ 2004-11-04 15:48 ` B. Anyos
2004-11-05 0:15 ` Richard Stallman
2004-11-04 17:05 ` Jan D.
2 siblings, 1 reply; 22+ messages in thread
From: B. Anyos @ 2004-11-04 15:48 UTC (permalink / raw)
Cc: chenggao, rms, Jason Rumney
It is true, I'm running emacs on Windows. So stacktrace is stopped right in
the middle of Fx_create_frame, though it seems it is over BLOCK_INPUT.
(file w32fns.c)
Anyway I tried to do what you asked for. Here's what I could figure out.
debug_print(args[0]):
face-set-after-frame-default
(struct Lisp_String *)(0xfffffff & ((struct Lisp_Symbol *) (0xfffffff & args[0]))->xname):
size 28
size_byte -1
intervals 0x00000000
data 0x01185dd0 "face-set-after-frame-default"
I hope this helps.
Unfortunately those nice commands listed in .gdbinit do not exist on MS Windows.
Any alternatives to help debugging on Windows ?
Jason Rumney said the following on 11/4/2004 11:31 AM:
> Richard Stallman wrote:
>
>> For instance, there is something really strange here:
>>
>> funcall_lambda(int -2128849612, int 1, int * 0x0082f980) line 2946
>> + 17 bytes
>> Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
>> call1(int 556794192, int -2127346688) line 2547 + 11 bytes
>> Fx_create_frame(int 0) line 4355
>>
>> There is no call to Fx_create_frame in line 4355; in fact, line 4355
>> is far after the end of Fx_create_frame. What's going on?
>>
> I think the user is on Windows, so that would be line 4355 of w32fns.c,
> which is in Fx_create_frame.
>
> My line numbers are slightly out, but I suspect this line (4350 in my
> version):
>
> /* Set up faces after all frame parameters are known. This call
> also merges in face attributes specified for new frames. If we
> don't do this, the `menu' face for instance won't have the right
> colors, and the menu bar won't appear in the specified colors for
> new frames. */
> call1 (Qface_set_after_frame_default, frame);
>
>
> It appears to be outside the BLOCK_INPUT blocks within x_create_frame.
>
>
>
> _______________________________________________
> Emacs-devel mailing list
> Emacs-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/emacs-devel
>
>
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs crash
2004-11-04 10:31 ` Jason Rumney
2004-11-04 12:52 ` B. Anyos
2004-11-04 15:48 ` B. Anyos
@ 2004-11-04 17:05 ` Jan D.
2004-11-05 8:03 ` Stefan
2 siblings, 1 reply; 22+ messages in thread
From: Jan D. @ 2004-11-04 17:05 UTC (permalink / raw)
Cc: B. Anyos, chenggao, rms, Jason Rumney
Jason Rumney wrote:
> Richard Stallman wrote:
>
>> For instance, there is something really strange here:
>>
>> funcall_lambda(int -2128849612, int 1, int * 0x0082f980) line 2946
>> + 17 bytes
>> Ffuncall(int -2147483648, int * 0x0082f980) line 2814 + 12 bytes
>> call1(int 556794192, int -2127346688) line 2547 + 11 bytes
>> Fx_create_frame(int 0) line 4355
>>
>> There is no call to Fx_create_frame in line 4355; in fact, line 4355
>> is far after the end of Fx_create_frame. What's going on?
>>
> I think the user is on Windows, so that would be line 4355 of w32fns.c,
> which is in Fx_create_frame.
>
> My line numbers are slightly out, but I suspect this line (4350 in my
> version):
>
> /* Set up faces after all frame parameters are known. This call
> also merges in face attributes specified for new frames. If we
> don't do this, the `menu' face for instance won't have the right
> colors, and the menu bar won't appear in the specified colors for
> new frames. */
> call1 (Qface_set_after_frame_default, frame);
>
>
> It appears to be outside the BLOCK_INPUT blocks within x_create_frame.
It is outside the BLOCK_INPUT in x_create_frame, but inside another
BLOCK_INPUT.
Installed cygwin, and tried to build. Here is what I get:
#19 0x0114b433 in realize_x_face (cache=0x1b86140, attrs=0x82ec40, c=0,
base_face=0x0) at xfaces.c:7141
#20 0x0114b2ce in realize_face (cache=0x1b86140, attrs=0x82ec40, c=0,
base_face=0x0, former_face_id=0) at xfaces.c:7040
#21 0x0114ac0b in realize_default_face (f=0x16ce800) at xfaces.c:6967
#22 0x0114a942 in realize_basic_faces (f=0x16ce800) at xfaces.c:6834
#23 0x01149879 in Fdisplay_supports_face_attributes_p (attributes=23649197,
display=23914500) at xfaces.c:6132
#24 0x0101c9c6 in Ffuncall (nargs=3, args=0x82ede0) at eval.c:2760
#25 0x0110491e in Fbyte_code (bytestr=18487971, vector=18488188,
maxdepth=40)
at bytecode.c:686
#26 0x0101cdac in funcall_lambda (fun=18487924, nargs=2,
arg_vector=0x82ef24)
at eval.c:2944
Number 23: Fdisplay_supports_face_attributes_p calls
realize_basic_faces, which does BLOCK_INPUT before calling
realize_default_face.
xbacktrace:
"replace-regexp-in-string"
"tty-color-canonicalize"
"tty-color-desc"
"display-supports-face-attributes-p"
"face-spec-set-match-display"
"face-spec-choose"
"face-spec-set"
"byte-code"
"face-set-after-frame-default"
"x-create-frame"
"x-create-frame-with-faces"
"make-frame"
"frame-initialize"
"command-line"
"normal-top-level"
Why does W32 have to do "call1 (Qface_set_after_frame_default, frame);"?
The other platforms (Mac and X) does not. NOTE: I am not at all
familiar with W32, there might be a good reason.
Jan D.
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs crash
2004-11-04 15:48 ` B. Anyos
@ 2004-11-05 0:15 ` Richard Stallman
0 siblings, 0 replies; 22+ messages in thread
From: Richard Stallman @ 2004-11-05 0:15 UTC (permalink / raw)
Cc: chenggao, jasonr, emacs-devel
(struct Lisp_String *)(0xfffffff & ((struct Lisp_Symbol *) (0xfffffff & args[0]))->xname):
size 28
size_byte -1
intervals 0x00000000
data 0x01185dd0 "face-set-after-frame-default"
I hope this helps.
It does help. This shows that BLOCK_INPUT wasn't done in
Fx_create_frame. I wonder where it was done?
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs crash
2004-11-04 17:05 ` Jan D.
@ 2004-11-05 8:03 ` Stefan
0 siblings, 0 replies; 22+ messages in thread
From: Stefan @ 2004-11-05 8:03 UTC (permalink / raw)
Cc: B. Anyos, chenggao, Jason Rumney, rms, emacs-devel
> Why does W32 have to do "call1 (Qface_set_after_frame_default, frame);"?
> The other platforms (Mac and X) does not. NOTE: I am not at all familiar
> with W32, there might be a good reason.
IIRC X used to do it as well, so maybe someone just forgot to remove it
from w32?
Stefan
^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: emacs crash
2004-11-04 13:08 ` Dhruva Krishnamurthy
@ 2004-11-05 8:38 ` Cheng Gao
0 siblings, 0 replies; 22+ messages in thread
From: Cheng Gao @ 2004-11-05 8:38 UTC (permalink / raw)
As I remember, this bug should occur since Nov. 2. You can use
cvs update -D "2004-11-1"
to revert to Nov. 1 source. Thus you can build a workable Emacs and wait
for fix of this bug.
HTH,
--
这去者，不能见他的脸，背影模糊。
^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2004-11-05 8:38 UTC | newest]
Thread overview: 22+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-11-03 9:55 emacs crash B. Anyos
2004-11-03 10:28 ` Jason Rumney
2004-11-03 10:50 ` B. Anyos
2004-11-03 11:21 ` Jason Rumney
2004-11-03 11:29 ` Dhruva Krishnamurthy
2004-11-03 12:02 ` B. Anyos
2004-11-03 11:06 ` Dhruva Krishnamurthy
2004-11-03 14:09 ` CHENG Gao
2004-11-03 15:02 ` B. Anyos
2004-11-04 9:51 ` Richard Stallman
2004-11-04 10:31 ` Jason Rumney
2004-11-04 12:52 ` B. Anyos
2004-11-04 13:08 ` Dhruva Krishnamurthy
2004-11-05 8:38 ` Cheng Gao
2004-11-04 15:48 ` B. Anyos
2004-11-05 0:15 ` Richard Stallman
2004-11-04 17:05 ` Jan D.
2004-11-05 8:03 ` Stefan
2004-11-04 9:51 ` Richard Stallman
-- strict thread matches above, loose matches on Subject: below --
2003-10-08 12:42 Werner LEMBERG
2003-08-16 13:56 Werner LEMBERG
2003-08-18 4:52 ` Richard Stallman
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).