* bug#10035: Crash in check_x_frame in w32fns.c
@ 2011-11-13 15:29 Christoph Scholtes
2011-11-13 17:18 ` Eli Zaretskii
0 siblings, 1 reply; 36+ messages in thread
From: Christoph Scholtes @ 2011-11-13 15:29 UTC (permalink / raw)
To: 10035
Emacs crashed while editing a Changelog.
Crashed session is still running under gdb. I can provide more details
if necessary.
Full backtrace:
#0 0x7557280d in KERNELBASE!DeleteAce ()
from C:\Windows\syswow64\KernelBase.dll
No symbol table info available.
#1 0x0115050f in w32_abort () at w32fns.c:233
button = 6
#2 0x010ee0d5 in row_equal_p (a=0x10dc2158, b=0x10d97158, mouse_face_p=1)
at dispnew.c:398
No locals.
#3 0x010f490f in scrolling_window (w=0x10d96000, header_line_p=0)
at dispnew.c:398
d = (struct glyph_row *) 0x10d97158
c = (struct glyph_row *) 0x10dc2158
desired_matrix = (struct glyph_matrix *) 0x10d6c900
current_matrix = (struct glyph_matrix *) 0x10d03200
yb = 252
i = 2
j = 282865180
first_old = 282689052
first_new = 282865180
last_old = 83
last_new = 283016440
nruns = 282689052
run_idx = 21981248
n = 17764412
entry = (struct row_entry *) 0x10d97e1c
rif = (struct redisplay_interface *) 0x14f6840
#4 0x010f30fe in update_window (w=0x10d96000, force_p=1) at dispnew.c:398
rc = -1
end = (struct glyph_row *) 0x10d97e1c
mode_line_row = (struct glyph_row *) 0x10d97e1c
header_line_row = (struct glyph_row *) 0x0
changed_p = 0
mouse_face_overwritten_p = 0
row = (struct glyph_row *) 0x10d97000
yb = 252
desired_matrix = (struct glyph_matrix *) 0x10d6c900
paused_p = 18876060
rif = (struct redisplay_interface *) 0x14f6840
#5 0x010f27fe in update_window_tree (w=0x10d96000, force_p=1)
at dispnew.c:398
paused_p = 0
#6 0x010f27d7 in update_window_tree (w=0x10d72200, force_p=1)
at dispnew.c:398
paused_p = 0
#7 0x010f254d in update_frame (f=0x3a24e00, force_p=1,
inhibit_hairy_id_p=0)
at dispnew.c:398
paused_p = 0
root_window = (struct window *) 0x10d72200
#8 0x011ff16e in redisplay_internal () at character.h:566
mini_window = 0
mini_frame = (struct frame *) 0x10bdf856
w = (struct window *) 0x10d96000
sw = (struct window *) 0x10d96000
fr = (struct frame *) 0x3a24e00
pending = 0
must_finish = 1
tlbufpos = {charpos = 62, bytepos = 62}
tlendpos = {charpos = 314156, bytepos = 314255}
number_of_visible_frames = 1
count = 2
count1 = 4
sf = (struct frame *) 0x3a24e00
polling_stopped_here = 1
old_frame = 60968453
consider_all_windows_p = 0
#9 0x011fbb1a in redisplay () at character.h:566
No locals.
#10 0x01008990 in read_char (commandflag=1, nmaps=5, maps=0x88f960,
prev_event=54765594, used_mouse_menu=0x88fa48, end_time=0x0)
at buffer.h:1045
echo_current = 1
c = 54765594
jmpcount = 8976696
local_getcjmp = {0, 17706273, 21888768, 8976547, 8976504, 16999231,
1, 32, 0, 17706212, 19943633, 54765594, 283464134, 54765594, 1, 32}
save_jump = {8976408, 19276185, 283352830, 54809442, 0, 1, 0,
54809442, 8976680, 17823167, 404, 54809442, 282042885, 20499101,
17703639,
32}
key_already_recorded = 0
tem = 283380534
save = 54765594
previous_echo_area_message = 54765594
also_record = 54765594
reread = 0
gcpro1 = {next = 0x12d0111, var = 0x10e39efe, nvars = 54809442}
gcpro2 = {next = 0x66, var = 0x0, nvars = 8976376}
polling_stopped_here = 0
orig_kboard = (struct kboard *) 0x38fc500
#11 0x0101c241 in read_key_sequence (keybuf=0x88fbd0, bufsize=30,
prompt=54765594, dont_downcase_last=0, can_return_switch_frame=1,
fix_current_buffer=1) at buffer.h:1045
interrupted_kboard = (KBOARD *) 0x38fc500
interrupted_frame = (struct frame *) 0x3a24e00
key = 404
used_mouse_menu = 0
echo_local_start = 0
last_real_key_start = 0
keys_local_start = 0
local_first_binding = 0
from_string = 54765594
count = 2
t = 0
echo_start = 0
keys_start = 0
nmaps = 5
nmaps_allocated = 5
defs = (Lisp_Object *) 0x88f930
submaps = (Lisp_Object *) 0x88f960
orig_local_map = 282935006
orig_keymap = 54765594
localized_local_map = 0
first_binding = 0
first_unbound = 31
mock_input = 0
fkey = {parent = 59280334, map = 59280334, start = 0, end = 0}
keytran = {parent = 54755014, map = 54755014, start = 0, end = 0}
indec = {parent = 59280342, map = 59280342, start = 0, end = 0}
shift_translated = 0
delayed_switch_frame = 54765594
original_uppercase = 404
original_uppercase_position = -1
dummyflag = 0
starting_buffer = (struct buffer *) 0x10cfa200
fake_prefixed_keys = 54765594
outer_gcpro1 = {next = 0x10d1ac38, var = 0x343a81a, nvars = 283380590}
#12 0x01005bf4 in command_loop_1 () at buffer.h:1045
cmd = 54993114
keybuf = {54907458, 208, 388, 2130567168, 0, 0, 8977432, 16798076,
282593638, 54765618, 8977471, 54885546, 0, 0, 8977464, 60968448,
54870858,
2130567168, 8977544, 16797445, 282593654, 8977471, 0, 2130567168, 0, 0,
8977512, 214704, 2, 54743622}
i = 1
prev_modiff = 89
prev_buffer = (struct buffer *) 0x10cfa200
already_adjusted = 0
#13 0x01032de7 in internal_condition_case (bfun=0x10055fc <command_loop_1>,
handlers=54823322, hfun=0x1004e1b <cmd_error>) at eval.c:169
val = 54743622
c = {tag = 54765594, val = 54765594, next = 0x88fd74, gcpro = 0x0,
jmp = {8977720, 0, 0, 0, 8977548, 16985492, 8978372, 0, 12456104,
8977684,
1968608529, 12456104, 1, 1958752824, 0, 1033}, backlist = 0x0,
handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2,
poll_suppress_count = 0, interrupt_input_blocked = 0, byte_stack = 0x0}
h = {handler = 54823322, var = 54765594, chosen_clause = 54765618,
tag = 0x88fcc0, next = 0x0}
#14 0x01005258 in command_loop_2 (ignore=54765594) at buffer.h:1045
val = 0
#15 0x0103280a in internal_catch (tag=54821346,
func=0x1005234 <command_loop_2>, arg=54765594) at eval.c:169
c = {tag = 54821346, val = 54765594, next = 0x0, gcpro = 0x0, jmp = {
8977896, 2130567168, 0, 0, 8977756, 16984059, 8978372, 0, 54765594,
54804480, 1958754112, 1958754175, 2130567168, 23257352, 54804480,
23257352}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0,
pdlcount = 2, poll_suppress_count = 0, interrupt_input_blocked = 0,
byte_stack = 0x0}
#16 0x01005214 in command_loop () at buffer.h:1045
No locals.
#17 0x034481e2 in _Jv_RegisterClasses ()
No symbol table info available.
#18 0x01005234 in command_loop () at buffer.h:1045
No locals.
#19 0x0343a81a in _Jv_RegisterClasses ()
No symbol table info available.
#20 0x00000001 in ?? ()
No symbol table info available.
#21 0x00000000 in ?? ()
No symbol table info available.
In GNU Emacs 24.0.91.1 (i386-mingw-nt6.1.7601)
of 2011-11-13 on MARVIN
Windowing system distributor `Microsoft Corp.', version 6.1.7601
configured using `configure --with-gcc (4.6) --no-opt --cflags
-I"D:/devel/emacs/libs/libXpm-3.5.8/include"
-I"D:/devel/emacs/libs/libXpm-3.5.8/src"
-I"D:/devel/emacs/libs/libpng-dev_1.4.3-1/include"
-I"D:/devel/emacs/libs/zlib-dev_1.2.5-2/include"
-I"D:/devel/emacs/libs/giflib-4.1.4-1/include"
-I"D:/devel/emacs/libs/jpeg-6b-4/include"
-I"D:/devel/emacs/libs/tiff-3.8.2-1/include"
-I"D:/devel/emacs/libs/gnutls-2.10.1/include" --ldflags
-L"D:/devel/emacs/libs/gnutls-2.10.1/lib"'
^ permalink raw reply [flat|nested] 36+ messages in thread* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-13 15:29 bug#10035: Crash in check_x_frame in w32fns.c Christoph Scholtes @ 2011-11-13 17:18 ` Eli Zaretskii 2011-11-13 20:04 ` Christoph Scholtes 0 siblings, 1 reply; 36+ messages in thread From: Eli Zaretskii @ 2011-11-13 17:18 UTC (permalink / raw) To: Christoph Scholtes; +Cc: 10035 > Date: Sun, 13 Nov 2011 08:29:34 -0700 > From: Christoph Scholtes <cschol2112@googlemail.com> > > Emacs crashed while editing a Changelog. > > Crashed session is still running under gdb. I can provide more details > if necessary. > > Full backtrace: > > #0 0x7557280d in KERNELBASE!DeleteAce () > from C:\Windows\syswow64\KernelBase.dll > No symbol table info available. > #1 0x0115050f in w32_abort () at w32fns.c:233 > button = 6 > #2 0x010ee0d5 in row_equal_p (a=0x10dc2158, b=0x10d97158, mouse_face_p=1) > at dispnew.c:398 The beast entered the trap. Please show what this produces: (gdb) p a->enabled_p (gdb) p b->enabled_p ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-13 17:18 ` Eli Zaretskii @ 2011-11-13 20:04 ` Christoph Scholtes 2011-11-13 20:21 ` Eli Zaretskii 0 siblings, 1 reply; 36+ messages in thread From: Christoph Scholtes @ 2011-11-13 20:04 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 10035 On 11/13/2011 10:18 AM, Eli Zaretskii wrote: > The beast entered the trap. Please show what this produces: > > (gdb) p a->enabled_p > (gdb) p b->enabled_p No symbol "a" in current context. No symbol "b" in current context. Emacs crashed and I hooked up with gdb after the crash. Then issued continue and closed the dialog box. Then produced the backtrace. That's where it is sitting now. Anything else I am missing? ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-13 20:04 ` Christoph Scholtes @ 2011-11-13 20:21 ` Eli Zaretskii 2011-11-13 20:42 ` Juanma Barranquero 2011-11-13 20:55 ` Christoph Scholtes 0 siblings, 2 replies; 36+ messages in thread From: Eli Zaretskii @ 2011-11-13 20:21 UTC (permalink / raw) To: Christoph Scholtes; +Cc: 10035 > Date: Sun, 13 Nov 2011 13:04:59 -0700 > From: Christoph Scholtes <cschol2112@googlemail.com> > CC: 10035@debbugs.gnu.org > > On 11/13/2011 10:18 AM, Eli Zaretskii wrote: > > > The beast entered the trap. Please show what this produces: > > > > (gdb) p a->enabled_p > > (gdb) p b->enabled_p > > No symbol "a" in current context. > No symbol "b" in current context. Sorry, I meant to type this in frame #2, where a and be are arguments of the function row_equal_p: > #2 0x010ee0d5 in row_equal_p (a=0x10dc2158, b=0x10d97158, mouse_face_p=1) > at dispnew.c:398 Btw, what's up with the messed up line numbers in dispnew.c? Observe: #2 0x010ee0d5 in row_equal_p (a=0x10dc2158, b=0x10d97158, mouse_face_p=1) at dispnew.c:398 #3 0x010f490f in scrolling_window (w=0x10d96000, header_line_p=0) at dispnew.c:398 #4 0x010f30fe in update_window (w=0x10d96000, force_p=1) at dispnew.c:398 #5 0x010f27fe in update_window_tree (w=0x10d96000, force_p=1) at dispnew.c:398 #6 0x010f27d7 in update_window_tree (w=0x10d72200, force_p=1) at dispnew.c:398 #7 0x010f254d in update_frame (f=0x3a24e00, force_p=1, inhibit_hairy_id_p=0) at dispnew.c:398 We are obviously very smart if we succeeded to squeeze all these functions into a single source line ;-) What version of GCC is that? ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-13 20:21 ` Eli Zaretskii @ 2011-11-13 20:42 ` Juanma Barranquero 2011-11-14 3:56 ` Eli Zaretskii 2011-11-13 20:55 ` Christoph Scholtes 1 sibling, 1 reply; 36+ messages in thread From: Juanma Barranquero @ 2011-11-13 20:42 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Christoph Scholtes, 10035 I'm hitting which I think is the same bug: Breakpoint 1, w32_abort () at w32fns.c:7190 7190 button = MessageBox (NULL,(gdb) bt #0 w32_abort () at w32fns.c:7190 #1 0x010ee13d in row_equal_p (a=0x508a158, b=0x4fcd158, mouse_face_p=1) at dispnew.c:1294 #2 0x010f498b in scrolling_window (w=0x3974800, header_line_p=0) at dispnew.c:4305 #3 0x010f317a in update_window (w=0x3974800, force_p=1) at dispnew.c:3605 #4 0x010f287a in update_window_tree (w=0x3974800, force_p=1) at dispnew.c:3349 #5 0x010f2853 in update_window_tree (w=0x3974c00, force_p=1) at dispnew.c:3347 #6 0x010f25c9 in update_frame (f=0x3a2ce00, force_p=1, inhibit_hairy_id_p=0) at dispnew.c:3276 #7 0x011fec83 in redisplay_internal () at xdisp.c:13175 #8 0x011ffb84 in redisplay_preserve_echo_area (from_where=12) at xdisp.c:13389 #9 0x0104c131 in wait_reading_process_output (time_limit=300, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=54720538, wait_proc=0x0, just_wait_proc=0) at process.c:4822 #10 0x010f99d9 in sit_for (timeout=1200, reading=1, do_display=1) at dispnew.c:5994 #11 0x01009253 in read_char (commandflag=1, nmaps=4, maps=0x88f970, prev_event=54720538, used_mouse_menu=0x88fa48, end_time=0x0) at keyboard.c:2687 #12 0x0101c2bd in read_key_sequence (keybuf=0x88fbd0, bufsize=30, prompt=54720538, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9290 #13 0x01005c70 in command_loop_1 () at keyboard.c:1447 #14 0x01032e63 in internal_condition_case (bfun=0x1005678 <command_loop_1>, handlers=54778266, hfun=0x1004e97 <cmd_error>) at eval.c:1499 #15 0x010052d4 in command_loop_2 (ignore=54720538) at keyboard.c:1158 #16 0x01032886 in internal_catch (tag=54776290, func=0x10052b0 <command_loop_2>, arg=54720538) at eval.c:1256 #17 0x01005290 in command_loop () at keyboard.c:1137 #18 0x0100486c in recursive_edit_1 () at keyboard.c:757 #19 0x01004b87 in Frecursive_edit () at keyboard.c:821 #20 0x010028b5 in main (argc=1, argv=0xa72c68) at emacs.c:1707 > Sorry, I meant to type this in frame #2, where a and be are arguments > of the function row_equal_p: (gdb) frame 1 #1 0x010ee13d in row_equal_p (a=0x508a158, b=0x4fcd158, mouse_face_p=1) at dispnew.c:1294 1294 xassert (verify_row_hash (a)); (gdb) p a->enabled_p $3 = 1 (gdb) p b->enabled_p $4 = 1 (gdb) I can reproduce it at will, but not from "emacs -Q". It happens for me when trying to run slime + sbcl. Output of "bt full" follows. Juanma (gdb) bt full #0 w32_abort () at w32fns.c:7190 button = 0 #1 0x010ee13d in row_equal_p (a=0x508a158, b=0x4fcd158, mouse_face_p=1) at dispnew.c:1294 No locals. #2 0x010f498b in scrolling_window (w=0x3974800, header_line_p=0) at dispnew.c:4305 d = 0x4fcd158 c = 0x508a158 desired_matrix = 0x5330380 current_matrix = 0x52ffc00 yb = 465 i = 2 j = 84461132 first_old = 83686988 first_new = 84461132 last_old = 124 last_new = 87995232 nruns = 83686988 run_idx = 21981248 n = 17764536 entry = 0x4fcf64c rif = 0x14f6840 #3 0x010f317a in update_window (w=0x3974800, force_p=1) at dispnew.c:3605 rc = -1 end = 0x4fcf64c mode_line_row = 0x4fcf64c header_line_row = 0x0 changed_p = 0 mouse_face_overwritten_p = 0 row = 0x4fcd000 yb = 465 desired_matrix = 0x5330380 paused_p = 0 rif = 0x14f6840 #4 0x010f287a in update_window_tree (w=0x3974800, force_p=1) at dispnew.c:3349 paused_p = 0 #5 0x010f2853 in update_window_tree (w=0x3974c00, force_p=1) at dispnew.c:3347 paused_p = 0 #6 0x010f25c9 in update_frame (f=0x3a2ce00, force_p=1, inhibit_hairy_id_p=0) at dispnew.c:3276 paused_p = 0 root_window = 0x3974c00 #7 0x011fec83 in redisplay_internal () at xdisp.c:13175 f = 0x3a2ce00 tail = 59282974 frame = 61001221 w = 0x3974800 sw = 0x3974800 fr = 0x3a2ce00 pending = 0 must_finish = 1 tlbufpos = { charpos = 342, bytepos = 342 } tlendpos = { charpos = 0, bytepos = 0 } number_of_visible_frames = 1 count = 3 count1 = 5 sf = 0x3a2ce00 polling_stopped_here = 1 old_frame = 61001221 consider_all_windows_p = 1 #8 0x011ffb84 in redisplay_preserve_echo_area (from_where=12) at xdisp.c:13389 No locals. #9 0x0104c131 in wait_reading_process_output (time_limit=300, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=54720538, wait_proc=0x0, just_wait_proc=0) at process.c:4822 nread = 261 timeout_reduced_for_timers = 1 channel = 3 nfds = 1 Available = { bits = {0, 0} } Writeok = { bits = {0, 0} } check_write = 0 check_delay = 1 no_avail = 0 xerrno = 22 proc = 60705797 timeout = { tv_sec = 0, tv_usec = 179000 } end_time = { tv_sec = 1321216849, tv_usec = 259000 } wait_channel = -1 got_some_input = 1 count = 2 #10 0x010f99d9 in sit_for (timeout=1200, reading=1, do_display=1) at dispnew.c:5994 sec = 300 usec = 0 #11 0x01009253 in read_char (commandflag=1, nmaps=4, maps=0x88f970, prev_event=54720538, used_mouse_menu=0x88fa48, end_time=0x0) at keyboard.c:2687 tem0 = 8976680 timeout = 300 delay_level = 4 buffer_size = 2 c = 54720538 jmpcount = 2 local_getcjmp = {8976680, 60417664, 8976760, 60417672, 8976300, 16812939, 8978372, 0, 101, 0, 0, 60417664, 8976568, 16939745, 56133544, 56297856} save_jump = {0 <repeats 16 times>} key_already_recorded = 0 tem = 82319702 save = 342 previous_echo_area_message = 54720538 also_record = 54720538 reread = 0 gcpro1 = { next = 0x1262215, var = 0x53ae98e, nvars = 54764386 } gcpro2 = { next = 0x343a362, var = 0x10f, nvars = 8976408 } polling_stopped_here = 0 orig_kboard = 0x38ea980 #12 0x0101c2bd in read_key_sequence (keybuf=0x88fbd0, bufsize=30, prompt=54720538, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9290 interrupted_kboard = 0x38ea980 interrupted_frame = 0x3a2ce00 key = 83529221 used_mouse_menu = 0 echo_local_start = 0 last_real_key_start = 0 keys_local_start = 0 local_first_binding = 0 from_string = 54720538 count = 2 t = 0 echo_start = 0 keys_start = 0 nmaps = 4 nmaps_allocated = 4 defs = 0x88f950 submaps = 0x88f970 orig_local_map = 86338862 orig_keymap = 54720538 localized_local_map = 0 first_binding = 0 first_unbound = 31 mock_input = 0 fkey = { parent = 59285670, map = 59285670, start = 0, end = 0 } keytran = { parent = 54709958, map = 54709958, start = 0, end = 0 } indec = { parent = 59285678, map = 59285678, start = 0, end = 0 } shift_translated = 0 delayed_switch_frame = 54720538 original_uppercase = 54825298 original_uppercase_position = -1 dummyflag = 0 starting_buffer = 0x4fa8e00 fake_prefixed_keys = 54720538 outer_gcpro1 = { next = 0x162f5e4, var = 0x342f81a, nvars = 83529216 } #13 0x01005c70 in command_loop_1 () at keyboard.c:1447 cmd = 54776506 keybuf = {536871392, 196, 8977388, 8977120, 0, 0, 54720538, 54825802, 54720538, 0, 0, 2130567168, 0, 0, 8977464, 17009385, 54825802, 54720538, 54698478, 54720538, 0, 54720538, 0, 2130567168, 0, 0, 8977512, 16992044, 2, 54698478} i = 1 prev_modiff = 16 prev_buffer = 0x4fa8400 already_adjusted = 0 #14 0x01032e63 in internal_condition_case (bfun=0x1005678 <command_loop_1>, handlers=54778266, hfun=0x1004e97 <cmd_error>) at eval.c:1499 val = 54698478 c = { tag = 54720538, val = 54720538, next = 0x88fd74, gcpro = 0x0, jmp = {8977720, 2130567168, 0, 0, 8977548, 16985616, 8978372, 0, 11291440, 8977684, 1968346385, 11291440, 1, 1973563960, 0, 3082}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 0, interrupt_input_blocked = 0, byte_stack = 0x0 } h = { handler = 54778266, var = 54720538, chosen_clause = 1996562125, tag = 0x88fcc0, next = 0x0 } #15 0x010052d4 in command_loop_2 (ignore=54720538) at keyboard.c:1158 val = 2130567168 #16 0x01032886 in internal_catch (tag=54776290, func=0x10052b0 <command_loop_2>, arg=54720538) at eval.c:1256 c = { tag = 54776290, val = 54720538, next = 0x0, gcpro = 0x0, jmp = {8977896, 2130567168, 0, 0, 8977756, 16984183, 8978372, 0, 54720538, 54759424, 1973565248, 1973565311, 2130567168, 23404840, 54759424, 23404840}, backlist = 0x0, handlerlist = 0x0, lisp_eval_depth = 0, pdlcount = 2, poll_suppress_count = 0, interrupt_input_blocked = 0, byte_stack = 0x0 } #17 0x01005290 in command_loop () at keyboard.c:1137 No locals. #18 0x0100486c in recursive_edit_1 () at keyboard.c:757 count = 1 val = 1972937794 #19 0x01004b87 in Frecursive_edit () at keyboard.c:821 count = 0 buffer = 54720538 #20 0x010028b5 in main (argc=1, argv=0xa72c68) at emacs.c:1707 dummy = 8978372 stack_bottom_variable = 0 '\000' do_initial_setlocale = 1 skip_args = 0 no_loadup = 0 junk = 0x0 dname_arg = 0x0 ch_to_dir = 0x0 (gdb) ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-13 20:42 ` Juanma Barranquero @ 2011-11-14 3:56 ` Eli Zaretskii 2011-11-14 8:57 ` Juanma Barranquero 0 siblings, 1 reply; 36+ messages in thread From: Eli Zaretskii @ 2011-11-14 3:56 UTC (permalink / raw) To: Juanma Barranquero; +Cc: cschol2112, 10035 > From: Juanma Barranquero <lekktu@gmail.com> > Date: Sun, 13 Nov 2011 21:42:58 +0100 > Cc: Christoph Scholtes <cschol2112@googlemail.com>, 10035@debbugs.gnu.org > > I'm hitting which I think is the same bug: > > Breakpoint 1, w32_abort () at w32fns.c:7190 > 7190 button = MessageBox (NULL,(gdb) bt > #0 w32_abort () at w32fns.c:7190 > #1 0x010ee13d in row_equal_p (a=0x508a158, b=0x4fcd158, > mouse_face_p=1) at dispnew.c:1294 > #2 0x010f498b in scrolling_window (w=0x3974800, header_line_p=0) at > dispnew.c:4305 Please show the info I asked Christoph to provide. It would help if you could provide a minimal recipe starting with "emacs -Q", even if that involves installing add-on packages. Thanks. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-14 3:56 ` Eli Zaretskii @ 2011-11-14 8:57 ` Juanma Barranquero 2011-11-14 11:23 ` Eli Zaretskii 0 siblings, 1 reply; 36+ messages in thread From: Juanma Barranquero @ 2011-11-14 8:57 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cschol2112, 10035 [-- Attachment #1: Type: text/plain, Size: 5297 bytes --] On Mon, Nov 14, 2011 at 04:56, Eli Zaretskii <eliz@gnu.org> wrote: > Please show the info I asked Christoph to provide. (gdb) p a->enabled_p $1 = 1 (gdb) p b->enabled_p $2 = 1 (gdb) prowx a y=75 x=0 pwid=320 a+d=12+3=15 phys=12+3=15 vis=15 L=0 T=40 R=0 start=419 end=459 ENA DISP (gdb) prowx b y=75 x=0 pwid=320 a+d=12+3=15 phys=12+3=15 vis=15 L=0 T=40 R=0 start=419 end=459 ENA DISP (gdb) pgrowx a TEXT: 40 glyphs 0 0: CHAR[ ] pos=419 blev=0,btyp=L w=8 a+d=12+3 MB 1 8: CHAR[ ] pos=420 blev=0,btyp=L w=8 a+d=12+3 MB 2 16: CHAR[ ] pos=421 blev=0,btyp=L w=8 a+d=12+3 MB 3 24: CHAR[ ] pos=422 blev=0,btyp=L w=8 a+d=12+3 MB 4 32: CHAR[ ] pos=423 blev=0,btyp=L w=8 a+d=12+3 MB 5 40: CHAR[=] pos=424 blev=0,btyp=L w=8 a+d=12+3 MB 6 48: CHAR[=] pos=425 blev=0,btyp=L w=8 a+d=12+3 MB 7 56: CHAR[=] pos=426 blev=0,btyp=L w=8 a+d=12+3 MB 8 64: CHAR[>] pos=427 blev=0,btyp=L w=8 a+d=12+3 MB 9 72: CHAR[ ] pos=428 blev=0,btyp=L w=8 a+d=12+3 MB 10 80: CHAR[r] pos=429 blev=0,btyp=L w=8 a+d=12+3 MB 11 88: CHAR[e] pos=430 blev=0,btyp=L w=8 a+d=12+3 MB 12 96: CHAR[t] pos=431 blev=0,btyp=L w=8 a+d=12+3 MB 13 104: CHAR[u] pos=432 blev=0,btyp=L w=8 a+d=12+3 MB 14 112: CHAR[r] pos=433 blev=0,btyp=L w=8 a+d=12+3 MB 15 120: CHAR[n] pos=434 blev=0,btyp=L w=8 a+d=12+3 MB 16 128: CHAR[e] pos=435 blev=0,btyp=L w=8 a+d=12+3 MB 17 136: CHAR[d] pos=436 blev=0,btyp=L w=8 a+d=12+3 MB 18 144: CHAR[ ] pos=437 blev=0,btyp=L w=8 a+d=12+3 MB 19 152: CHAR[#] pos=438 blev=0,btyp=L w=8 a+d=12+3 MB 20 160: CHAR[X] pos=439 blev=0,btyp=L w=8 a+d=12+3 MB 21 168: CHAR[0] pos=440 blev=0,btyp=L w=8 a+d=12+3 MB 22 176: CHAR[0] pos=441 blev=0,btyp=L w=8 a+d=12+3 MB 23 184: CHAR[0] pos=442 blev=0,btyp=L w=8 a+d=12+3 MB 24 192: CHAR[0] pos=443 blev=0,btyp=L w=8 a+d=12+3 MB 25 200: CHAR[0] pos=444 blev=0,btyp=L w=8 a+d=12+3 MB 26 208: CHAR[0] pos=445 blev=0,btyp=L w=8 a+d=12+3 MB 27 216: CHAR[0] pos=446 blev=0,btyp=L w=8 a+d=12+3 MB 28 224: CHAR[0] pos=447 blev=0,btyp=L w=8 a+d=12+3 MB 29 232: CHAR[0] pos=448 blev=0,btyp=L w=8 a+d=12+3 MB 30 240: CHAR[0] pos=449 blev=0,btyp=L w=8 a+d=12+3 MB 31 248: CHAR[0] pos=450 blev=0,btyp=L w=8 a+d=12+3 MB 32 256: CHAR[0] pos=451 blev=0,btyp=L w=8 a+d=12+3 MB 33 264: CHAR[0] pos=452 blev=0,btyp=L w=8 a+d=12+3 MB 34 272: CHAR[0] pos=453 blev=0,btyp=L w=8 a+d=12+3 MB 35 280: CHAR[0] pos=454 blev=0,btyp=L w=8 a+d=12+3 MB 36 288: CHAR[0] pos=455 blev=0,btyp=L w=8 a+d=12+3 MB 37 296: CHAR[,] pos=456 blev=0,btyp=L w=8 a+d=12+3 MB 38 304: CHAR[ ] pos=457 blev=0,btyp=L w=8 a+d=12+3 face=38 MB 39 312: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=12+3 MB (gdb) pgrowx b TEXT: 40 glyphs 0 0: CHAR[ ] pos=419 blev=0,btyp=L w=8 a+d=12+3 MB 1 8: CHAR[ ] pos=420 blev=0,btyp=L w=8 a+d=12+3 MB 2 16: CHAR[ ] pos=421 blev=0,btyp=L w=8 a+d=12+3 MB 3 24: CHAR[ ] pos=422 blev=0,btyp=L w=8 a+d=12+3 MB 4 32: CHAR[ ] pos=423 blev=0,btyp=L w=8 a+d=12+3 MB 5 40: CHAR[=] pos=424 blev=0,btyp=L w=8 a+d=12+3 MB 6 48: CHAR[=] pos=425 blev=0,btyp=L w=8 a+d=12+3 MB 7 56: CHAR[=] pos=426 blev=0,btyp=L w=8 a+d=12+3 MB 8 64: CHAR[>] pos=427 blev=0,btyp=L w=8 a+d=12+3 MB 9 72: CHAR[ ] pos=428 blev=0,btyp=L w=8 a+d=12+3 MB 10 80: CHAR[r] pos=429 blev=0,btyp=L w=8 a+d=12+3 MB 11 88: CHAR[e] pos=430 blev=0,btyp=L w=8 a+d=12+3 MB 12 96: CHAR[t] pos=431 blev=0,btyp=L w=8 a+d=12+3 MB 13 104: CHAR[u] pos=432 blev=0,btyp=L w=8 a+d=12+3 MB 14 112: CHAR[r] pos=433 blev=0,btyp=L w=8 a+d=12+3 MB 15 120: CHAR[n] pos=434 blev=0,btyp=L w=8 a+d=12+3 MB 16 128: CHAR[e] pos=435 blev=0,btyp=L w=8 a+d=12+3 MB 17 136: CHAR[d] pos=436 blev=0,btyp=L w=8 a+d=12+3 MB 18 144: CHAR[ ] pos=437 blev=0,btyp=L w=8 a+d=12+3 MB 19 152: CHAR[#] pos=438 blev=0,btyp=L w=8 a+d=12+3 MB 20 160: CHAR[X] pos=439 blev=0,btyp=L w=8 a+d=12+3 MB 21 168: CHAR[0] pos=440 blev=0,btyp=L w=8 a+d=12+3 MB 22 176: CHAR[0] pos=441 blev=0,btyp=L w=8 a+d=12+3 MB 23 184: CHAR[0] pos=442 blev=0,btyp=L w=8 a+d=12+3 MB 24 192: CHAR[0] pos=443 blev=0,btyp=L w=8 a+d=12+3 MB 25 200: CHAR[0] pos=444 blev=0,btyp=L w=8 a+d=12+3 MB 26 208: CHAR[0] pos=445 blev=0,btyp=L w=8 a+d=12+3 MB 27 216: CHAR[0] pos=446 blev=0,btyp=L w=8 a+d=12+3 MB 28 224: CHAR[0] pos=447 blev=0,btyp=L w=8 a+d=12+3 MB 29 232: CHAR[0] pos=448 blev=0,btyp=L w=8 a+d=12+3 MB 30 240: CHAR[0] pos=449 blev=0,btyp=L w=8 a+d=12+3 MB 31 248: CHAR[0] pos=450 blev=0,btyp=L w=8 a+d=12+3 MB 32 256: CHAR[0] pos=451 blev=0,btyp=L w=8 a+d=12+3 MB 33 264: CHAR[0] pos=452 blev=0,btyp=L w=8 a+d=12+3 MB 34 272: CHAR[0] pos=453 blev=0,btyp=L w=8 a+d=12+3 MB 35 280: CHAR[0] pos=454 blev=0,btyp=L w=8 a+d=12+3 MB 36 288: CHAR[0] pos=455 blev=0,btyp=L w=8 a+d=12+3 MB 37 296: CHAR[,] pos=456 blev=0,btyp=L w=8 a+d=12+3 MB 38 304: CHAR[ ] pos=457 blev=0,btyp=L w=8 a+d=12+3 face=38 MB 39 312: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=12+3 MB (gdb) I'm attaching a printscreen of the Emacs session. > It would help if you could provide a minimal recipe starting with > "emacs -Q", even if that involves installing add-on packages. I'll try, but I suspect it won't be easy. Juanma [-- Attachment #2: bug.png --] [-- Type: image/png, Size: 88280 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-14 8:57 ` Juanma Barranquero @ 2011-11-14 11:23 ` Eli Zaretskii 2011-11-14 11:44 ` Juanma Barranquero 0 siblings, 1 reply; 36+ messages in thread From: Eli Zaretskii @ 2011-11-14 11:23 UTC (permalink / raw) To: Juanma Barranquero; +Cc: cschol2112, 10035 > From: Juanma Barranquero <lekktu@gmail.com> > Date: Mon, 14 Nov 2011 09:57:17 +0100 > Cc: cschol2112@googlemail.com, 10035@debbugs.gnu.org > > > [1:text/plain Hide] > > On Mon, Nov 14, 2011 at 04:56, Eli Zaretskii <eliz@gnu.org> wrote: > > > Please show the info I asked Christoph to provide. > > (gdb) p a->enabled_p > $1 = 1 > (gdb) p b->enabled_p > $2 = 1 > (gdb) prowx a > y=75 x=0 pwid=320 a+d=12+3=15 phys=12+3=15 vis=15 L=0 T=40 R=0 > start=419 end=459 ENA DISP > (gdb) prowx b > y=75 x=0 pwid=320 a+d=12+3=15 phys=12+3=15 vis=15 L=0 T=40 R=0 > start=419 end=459 ENA DISP > (gdb) pgrowx a > TEXT: 40 glyphs Thanks. The 2 glyph rows are identical, AFAICS. The last (I hope ;-) piece of the puzzle is this: (gdb) p a->hash (gdb) p b->hash ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-14 11:23 ` Eli Zaretskii @ 2011-11-14 11:44 ` Juanma Barranquero 2011-11-14 13:35 ` Eli Zaretskii 0 siblings, 1 reply; 36+ messages in thread From: Juanma Barranquero @ 2011-11-14 11:44 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cschol2112, 10035 On Mon, Nov 14, 2011 at 12:23, Eli Zaretskii <eliz@gnu.org> wrote: > Thanks. The 2 glyph rows are identical, AFAICS. The last (I hope ;-) > piece of the puzzle is this: > > (gdb) p a->hash > (gdb) p b->hash (gdb) p a->hash $3 = 202770841 (gdb) p b->hash $4 = 202770841 (gdb) xtype Lisp_String (gdb) xstring $5 = (struct Lisp_String *) 0xc160998 Cannot access memory at address 0xc1609a4 Juanma ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-14 11:44 ` Juanma Barranquero @ 2011-11-14 13:35 ` Eli Zaretskii 2011-11-14 14:29 ` Juanma Barranquero 0 siblings, 1 reply; 36+ messages in thread From: Eli Zaretskii @ 2011-11-14 13:35 UTC (permalink / raw) To: Juanma Barranquero; +Cc: cschol2112, 10035 > From: Juanma Barranquero <lekktu@gmail.com> > Date: Mon, 14 Nov 2011 12:44:04 +0100 > Cc: cschol2112@googlemail.com, 10035@debbugs.gnu.org > > (gdb) p a->hash > $3 = 202770841 > (gdb) p b->hash > $4 = 202770841 Hmm... identical, but both wrong. Do you get these same values every time you reproduce the assertion violation, or are the hashes different each time? ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-14 13:35 ` Eli Zaretskii @ 2011-11-14 14:29 ` Juanma Barranquero 2011-11-14 15:46 ` Juanma Barranquero 2011-11-14 17:08 ` Eli Zaretskii 0 siblings, 2 replies; 36+ messages in thread From: Juanma Barranquero @ 2011-11-14 14:29 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cschol2112, 10035 On Mon, Nov 14, 2011 at 14:35, Eli Zaretskii <eliz@gnu.org> wrote: > Do you get these same values every time you reproduce the assertion > violation, or are the hashes different each time? No, I get the same values every time. Juanma ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-14 14:29 ` Juanma Barranquero @ 2011-11-14 15:46 ` Juanma Barranquero 2011-11-14 17:19 ` Eli Zaretskii 2011-11-14 17:08 ` Eli Zaretskii 1 sibling, 1 reply; 36+ messages in thread From: Juanma Barranquero @ 2011-11-14 15:46 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cschol2112, 10035 Another example, with a different recipe. I get this one by doing emacs w32proc.c ;; it has changes, so the diff is not empty C-x v = and, in the diff buffer, C-x h but not from -Q, alas. Breakpoint 1, w32_abort () at w32fns.c:7190 7190 button = MessageBox (NULL, (gdb) bt #0 w32_abort () at w32fns.c:7190 #1 0x010ee13d in row_equal_p (a=0x542a6b8, b=0x53776b8, mouse_face_p=1) at dispnew.c:1294 #2 0x010f498b in scrolling_window (w=0x39e1e00, header_line_p=0) at dispnew.c:4305 #3 0x010f317a in update_window (w=0x39e1e00, force_p=1) at dispnew.c:3605 #4 0x010f287a in update_window_tree (w=0x39e1e00, force_p=1) at dispnew.c:3349 #5 0x010f2853 in update_window_tree (w=0x39af200, force_p=1) at dispnew.c:3347 #6 0x010f25c9 in update_frame (f=0x3a2de00, force_p=1, inhibit_hairy_id_p=0) at dispnew.c:3276 #7 0x011ff1ea in redisplay_internal () at xdisp.c:13238 #8 0x011ffb84 in redisplay_preserve_echo_area (from_where=8) at xdisp.c:13389 #9 0x010205b7 in detect_input_pending_run_timers (do_display=1) at keyboard.c:10474 #10 0x0104bd45 in wait_reading_process_output (time_limit=300, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=54720538, wait_proc=0x0, just_wait_proc=0) at process.c:4701 #11 0x010f99d9 in sit_for (timeout=1200, reading=1, do_display=1) at dispnew.c:5994 #12 0x01009253 in read_char (commandflag=1, nmaps=6, maps=0x88f960, prev_event=54720538, used_mouse_menu=0x88fa48, end_time=0x0) at keyboard.c:2687 #13 0x0101c2bd in read_key_sequence (keybuf=0x88fbd0, bufsize=30, prompt=54720538, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1) at keyboard.c:9290 #14 0x01005c70 in command_loop_1 () at keyboard.c:1447 #15 0x01032e63 in internal_condition_case (bfun=0x1005678 <command_loop_1>, handlers=54778266, hfun=0x1004e97 <cmd_error>) at eval.c:1499 #16 0x010052d4 in command_loop_2 (ignore=54720538) at keyboard.c:1158 #17 0x01032886 in internal_catch (tag=54776290, func=0x10052b0 <command_loop_2>, arg=54720538) at eval.c:1256 #18 0x01005290 in command_loop () at keyboard.c:1137 #19 0x0100486c in recursive_edit_1 () at keyboard.c:757 #20 0x01004b87 in Frecursive_edit () at keyboard.c:821 #21 0x010028b5 in main (argc=1, argv=0xc32c68) at emacs.c:1707 (gdb) frame 1 #1 0x010ee13d in row_equal_p (a=0x542a6b8, b=0x53776b8, mouse_face_p=1) at dispnew.c:1294 1294 xassert (verify_row_hash (a)); (gdb) p a->enabled_p $1 = 1 (gdb) p b->enabled_p $2 = 1 (gdb) prowx a y=150 x=0 pwid=16 a+d=12+3=15 phys=12+3=15 vis=15 L=0 T=2 R=0 start=415 end=417 ENA DISP (gdb) prowx b y=150 x=0 pwid=16 a+d=12+3=15 phys=12+3=15 vis=15 L=0 T=2 R=0 start=415 end=417 ENA DISP (gdb) pgrowx a TEXT: 2 glyphs 0 0: CHAR[ ] pos=415 blev=0,btyp=L w=8 a+d=12+3 face=39 MB 1 8: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=12+3 face=43 MB (gdb) pgrowx b TEXT: 2 glyphs 0 0: CHAR[ ] pos=415 blev=0,btyp=L w=8 a+d=12+3 face=39 MB 1 8: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=12+3 face=43 MB (gdb) p a->hash $3 = 1275 (gdb) p b->hash $4 = 1275 ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-14 15:46 ` Juanma Barranquero @ 2011-11-14 17:19 ` Eli Zaretskii 0 siblings, 0 replies; 36+ messages in thread From: Eli Zaretskii @ 2011-11-14 17:19 UTC (permalink / raw) To: Juanma Barranquero; +Cc: cschol2112, 10035 > From: Juanma Barranquero <lekktu@gmail.com> > Date: Mon, 14 Nov 2011 16:46:29 +0100 > Cc: cschol2112@googlemail.com, 10035@debbugs.gnu.org > > (gdb) pgrowx a > TEXT: 2 glyphs > 0 0: CHAR[ ] pos=415 blev=0,btyp=L w=8 a+d=12+3 face=39 MB > 1 8: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=12+3 face=43 MB > (gdb) pgrowx b > TEXT: 2 glyphs > 0 0: CHAR[ ] pos=415 blev=0,btyp=L w=8 a+d=12+3 face=39 MB > 1 8: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=12+3 face=43 MB Can you try to find out which faces are those (face IDs 39 and 43)? Also, what was face 38 in the previous crash? ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-14 14:29 ` Juanma Barranquero 2011-11-14 15:46 ` Juanma Barranquero @ 2011-11-14 17:08 ` Eli Zaretskii 2011-11-14 17:20 ` Juanma Barranquero 2011-11-14 17:41 ` Juanma Barranquero 1 sibling, 2 replies; 36+ messages in thread From: Eli Zaretskii @ 2011-11-14 17:08 UTC (permalink / raw) To: Juanma Barranquero; +Cc: cschol2112, 10035 > From: Juanma Barranquero <lekktu@gmail.com> > Date: Mon, 14 Nov 2011 15:29:00 +0100 > Cc: cschol2112@googlemail.com, 10035@debbugs.gnu.org > > On Mon, Nov 14, 2011 at 14:35, Eli Zaretskii <eliz@gnu.org> wrote: > > > Do you get these same values every time you reproduce the assertion > > violation, or are the hashes different each time? > > No, I get the same values every time. Aha. And what is that red block the size of a cursor (but evidently not a cursor) at the end of the line which causes the abort? Where did that come from -- a buffer position with a special face? I'm past the line where debugging by asking questions stops being efficient. A reproducible test case would help tremendously, assuming it is feasible for you to come up with one. Or maybe I will see the light and either find the problem by code inspection or find some clever way to catch it and yet simple enough to ask you to do it. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-14 17:08 ` Eli Zaretskii @ 2011-11-14 17:20 ` Juanma Barranquero 2011-11-14 17:32 ` Juanma Barranquero 2011-11-14 17:41 ` Juanma Barranquero 1 sibling, 1 reply; 36+ messages in thread From: Juanma Barranquero @ 2011-11-14 17:20 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cschol2112, 10035 On Mon, Nov 14, 2011 at 18:08, Eli Zaretskii <eliz@gnu.org> wrote: > Aha. And what is that red block the size of a cursor (but evidently > not a cursor) at the end of the line which causes the abort? Where > did that come from -- a buffer position with a special face? I think another cursor, because I only set red at this: (setq cua-normal-cursor-color '(box . "black") cua-overwrite-cursor-color '(box . "red") cua-read-only-cursor-color '(hollow . "red"))) and a few places in the modeline. > A reproducible test case would help tremendously, assuming > it is feasible for you to come up with one. I'm trying, but the way my .emacs is structured, bisecting is hard. I'll eventually get a recipe, but it will take a while. Juanma ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-14 17:20 ` Juanma Barranquero @ 2011-11-14 17:32 ` Juanma Barranquero 0 siblings, 0 replies; 36+ messages in thread From: Juanma Barranquero @ 2011-11-14 17:32 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cschol2112, 10035 > I think another cursor, because I only set red at this: No, I think is trailing whitespace. I get the crash in the diffs when there's trailing whitespace, too, and I just got the crash by inserting a trailing whitespace... Juanma ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-14 17:08 ` Eli Zaretskii 2011-11-14 17:20 ` Juanma Barranquero @ 2011-11-14 17:41 ` Juanma Barranquero 2011-11-14 19:43 ` Eli Zaretskii 1 sibling, 1 reply; 36+ messages in thread From: Juanma Barranquero @ 2011-11-14 17:41 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cschol2112, 10035 On Mon, Nov 14, 2011 at 18:08, Eli Zaretskii <eliz@gnu.org> wrote: > A reproducible test case would help tremendously, assuming > it is feasible for you to come up with one. Here is one recipe that works for me: cd src gdb ..\bin\emacs.exe run -Q ChangeLog C-o C-a Juanma ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-14 17:41 ` Juanma Barranquero @ 2011-11-14 19:43 ` Eli Zaretskii 2011-11-14 20:18 ` Eli Zaretskii 0 siblings, 1 reply; 36+ messages in thread From: Eli Zaretskii @ 2011-11-14 19:43 UTC (permalink / raw) To: Juanma Barranquero; +Cc: cschol2112, 10035 > From: Juanma Barranquero <lekktu@gmail.com> > Date: Mon, 14 Nov 2011 18:41:54 +0100 > Cc: cschol2112@googlemail.com, 10035@debbugs.gnu.org > > On Mon, Nov 14, 2011 at 18:08, Eli Zaretskii <eliz@gnu.org> wrote: > > > A reproducible test case would help tremendously, assuming > > it is feasible for you to come up with one. > > Here is one recipe that works for me: > > cd src > gdb ..\bin\emacs.exe > run -Q ChangeLog > C-o > C-a Great, thanks. It looks like some code is adding a face, but does not update the row's hash value, and trailing-whitespace is the key. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-14 19:43 ` Eli Zaretskii @ 2011-11-14 20:18 ` Eli Zaretskii 2011-11-14 21:07 ` Juanma Barranquero 0 siblings, 1 reply; 36+ messages in thread From: Eli Zaretskii @ 2011-11-14 20:18 UTC (permalink / raw) To: lekktu, cschol2112, 10035 > Date: Mon, 14 Nov 2011 21:43:35 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: cschol2112@googlemail.com, 10035@debbugs.gnu.org > > > From: Juanma Barranquero <lekktu@gmail.com> > > Date: Mon, 14 Nov 2011 18:41:54 +0100 > > Cc: cschol2112@googlemail.com, 10035@debbugs.gnu.org > > > > On Mon, Nov 14, 2011 at 18:08, Eli Zaretskii <eliz@gnu.org> wrote: > > > > > A reproducible test case would help tremendously, assuming > > > it is feasible for you to come up with one. > > > > Here is one recipe that works for me: > > > > cd src > > gdb ..\bin\emacs.exe > > run -Q ChangeLog > > C-o > > C-a > > Great, thanks. It looks like some code is adding a face, but does not > update the row's hash value, and trailing-whitespace is the key. This one is fixed (revision 106372 on the trunk). Please check the other recipes. Thanks. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-14 20:18 ` Eli Zaretskii @ 2011-11-14 21:07 ` Juanma Barranquero 2011-11-15 0:43 ` Christoph Scholtes 0 siblings, 1 reply; 36+ messages in thread From: Juanma Barranquero @ 2011-11-14 21:07 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cschol2112, 10035 On Mon, Nov 14, 2011 at 21:18, Eli Zaretskii <eliz@gnu.org> wrote: > This one is fixed (revision 106372 on the trunk). Please check the > other recipes. They are all fixed too. Juanma ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-14 21:07 ` Juanma Barranquero @ 2011-11-15 0:43 ` Christoph Scholtes 2011-11-15 3:48 ` Eli Zaretskii 0 siblings, 1 reply; 36+ messages in thread From: Christoph Scholtes @ 2011-11-15 0:43 UTC (permalink / raw) To: Juanma Barranquero; +Cc: 10035 On 11/14/2011 2:07 PM, Juanma Barranquero wrote: > On Mon, Nov 14, 2011 at 21:18, Eli Zaretskii<eliz@gnu.org> wrote: > >> This one is fixed (revision 106372 on the trunk). Please check the >> other recipes. > > They are all fixed too. My recipe was similar: emacs -Q C-x 4 a Press `left arrow' key -> Crash and this is fixed too in the latest trunk. Thanks! ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-15 0:43 ` Christoph Scholtes @ 2011-11-15 3:48 ` Eli Zaretskii 2011-11-15 17:12 ` Juanma Barranquero 0 siblings, 1 reply; 36+ messages in thread From: Eli Zaretskii @ 2011-11-15 3:48 UTC (permalink / raw) To: Christoph Scholtes; +Cc: lekktu, 10035-done > Date: Mon, 14 Nov 2011 17:43:13 -0700 > From: Christoph Scholtes <cschol2112@googlemail.com> > CC: Eli Zaretskii <eliz@gnu.org>, 10035@debbugs.gnu.org > > On 11/14/2011 2:07 PM, Juanma Barranquero wrote: > > On Mon, Nov 14, 2011 at 21:18, Eli Zaretskii<eliz@gnu.org> wrote: > > > >> This one is fixed (revision 106372 on the trunk). Please check the > >> other recipes. > > > > They are all fixed too. > > My recipe was similar: > > emacs -Q > C-x 4 a > Press `left arrow' key > -> Crash > > and this is fixed too in the latest trunk. > > Thanks! Thanks; closing. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-15 3:48 ` Eli Zaretskii @ 2011-11-15 17:12 ` Juanma Barranquero 2011-11-15 18:00 ` Eli Zaretskii 0 siblings, 1 reply; 36+ messages in thread From: Juanma Barranquero @ 2011-11-15 17:12 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Christoph Scholtes, 10035 I just had another assertion failure in row_equal_p, which seems a variant of the bug you fixed. In this case, "pgrowx a" and "pgrowx b" do not show the same content, but a->hash == b->hash. I was just editing elisp code, and the assertion failure happened during an isearch for "lets". I'm keeping the gdb session open, in case you need more info. Program received signal SIGTRAP, Trace/breakpoint trap. [Switching to Thread 4268.0xa18] 0x7708280d in KERNELBASE!DeleteAce () from C:\Windows\syswow64\KernelBase.dll (gdb) bt #0 0x7708280d in KERNELBASE!DeleteAce () from C:\Windows\syswow64\KernelBase.dll #1 0x010fd40c in w32_abort () at w32fns.c:7204 #2 0x0107bb11 in row_equal_p (b=0x373e968, a=0x5d4f968, mouse_face_p=<optimized out>) at dispnew.c:1294 #3 scrolling_window (header_line_p=0, w=0x3ae5800) at dispnew.c:4305 #4 update_window (w=0x3ae5800, force_p=1) at dispnew.c:3605 #5 0x0107bd68 in update_window_tree (w=0x3ae5800, force_p=1) at dispnew.c:3349 #6 0x0107e92f in update_frame (f=0x3ae5e00, force_p=1, inhibit_hairy_id_p=0) at dispnew.c:3276 #7 0x01131466 in redisplay_internal () at xdisp.c:13238 #8 0x01131d82 in redisplay_preserve_echo_area (from_where=8) at xdisp.c:13389 #9 0x010315ca in detect_input_pending_run_timers (do_display=1) at keyboard.c:10474 #10 0x0101d296 in wait_reading_process_output (time_limit=600, microsecs=0, read_kbd=-1, do_display=1, wait_for_cell=55470106, wait_proc=0x0, just_wait_proc=0) at process.c:4701 #11 0x010802f6 in sit_for (timeout=2400, reading=1, do_display=1) at dispnew.c:5994 #12 0x01033f82 in read_char (commandflag=1, nmaps=2, maps=0x88fae0, prev_event=55470106, used_mouse_menu=0x88fbd8, end_time=0x0) at keyboard.c:2687 #13 0x0103576d in read_key_sequence (keybuf=0x88fc48, prompt=55470106, dont_downcase_last=0, can_return_switch_frame=1, fix_current_buffer=1, bufsize=30) at keyboard.c:9290 #14 0x01037cf9 in command_loop_1 () at keyboard.c:1447 #15 0x0101183b in internal_condition_case (bfun=0x1037aa0 <command_loop_1>, handlers=55527834, hfun=0x102a870 <cmd_error>) at eval.c:1499 #16 0x01028c2d in command_loop_2 (ignore=55470106) at keyboard.c:1158 #17 0x01011779 in internal_catch (tag=55525858, func=0x1028c00 <command_loop_2>, arg=55470106) at eval.c:1256 #18 0x0102a230 in command_loop () at keyboard.c:1137 #19 recursive_edit_1 () at keyboard.c:757 #20 0x0102a5a5 in Frecursive_edit () at keyboard.c:821 #21 0x01258e57 in main (argc=<optimized out>, argv=0x9b2cc0) at emacs.c:1707 (gdb) frame 2 #2 0x0107bb11 in row_equal_p (b=0x373e968, a=0x5d4f968, mouse_face_p=<optimized out>) at dispnew.c:1294 1294 xassert (verify_row_hash (a)); (gdb) p a->enabled_p $1 = 1 (gdb) p b->enabled_p $2 = 1 (gdb) prowx a y=210 x=0 pwid=128 a+d=12+3=15 phys=12+3=15 vis=15 L=0 T=16 R=0 start=60162 end=60178 ENA DISP (gdb) prowx b y=210 x=0 pwid=128 a+d=12+3=15 phys=12+3=15 vis=15 L=0 T=16 R=0 start=60162 end=60178 ENA DISP (gdb) pgrowx a TEXT: 16 glyphs 0 0: CHAR[S] pos=57996 blev=0,btyp=L w=8 a+d=12+3 face=39 MB 1 8: CHAR[l] pos=57997 blev=0,btyp=L w=8 a+d=12+3 face=39 MB 2 16: CHAR[o] pos=57998 blev=0,btyp=L w=8 a+d=12+3 face=39 MB 3 24: CHAR[t] pos=57999 blev=0,btyp=L w=8 a+d=12+3 face=39 MB 4 32: CHAR[ ] pos=58000 blev=0,btyp=L w=8 a+d=12+3 face=39 MB 5 40: CHAR[i] pos=58001 blev=0,btyp=L w=8 a+d=12+3 face=39 MB 6 48: CHAR[s] pos=58002 blev=0,btyp=L w=8 a+d=12+3 face=39 MB 7 56: CHAR[ ] pos=58003 blev=0,btyp=L w=8 a+d=12+3 face=39 MB 8 64: CHAR[t] pos=58004 blev=0,btyp=L w=8 a+d=12+3 face=39 MB 9 72: CHAR[h] pos=58005 blev=0,btyp=L w=8 a+d=12+3 face=39 MB 10 80: CHAR[e] pos=58006 blev=0,btyp=L w=8 a+d=12+3 face=39 MB 11 88: CHAR[ ] pos=58007 blev=0,btyp=L w=8 a+d=12+3 face=39 MB 12 96: CHAR[n] pos=58008 blev=0,btyp=L w=8 a+d=12+3 face=39 MB 13 104: CHAR[a] pos=58009 blev=0,btyp=L w=8 a+d=12+3 face=39 MB 14 112: CHAR[m] pos=58010 blev=0,btyp=L w=8 a+d=12+3 face=39 MB 15 120: CHAR[e] pos=58011 blev=0,btyp=L w=8 a+d=12+3 face=39 MB (gdb) pgrowx b TEXT: 16 glyphs 0 0: CHAR[ ] pos=60162 blev=0,btyp=L w=8 a+d=12+3 MB 1 8: CHAR[ ] pos=60163 blev=0,btyp=L w=8 a+d=12+3 MB 2 16: CHAR[ ] pos=60164 blev=0,btyp=L w=8 a+d=12+3 MB 3 24: CHAR[ ] pos=60165 blev=0,btyp=L w=8 a+d=12+3 MB 4 32: CHAR[(] pos=60166 blev=0,btyp=L w=8 a+d=12+3 MB 5 40: CHAR[i] pos=60167 blev=0,btyp=L w=8 a+d=12+3 face=26 MB 6 48: CHAR[f] pos=60168 blev=0,btyp=L w=8 a+d=12+3 face=26 MB 7 56: CHAR[ ] pos=60169 blev=0,btyp=L w=8 a+d=12+3 MB 8 64: CHAR[(] pos=60170 blev=0,btyp=L w=8 a+d=12+3 MB 9 72: CHAR[n] pos=60171 blev=0,btyp=L w=8 a+d=12+3 MB 10 80: CHAR[o] pos=60172 blev=0,btyp=L w=8 a+d=12+3 MB 11 88: CHAR[t] pos=60173 blev=0,btyp=L w=8 a+d=12+3 MB 12 96: CHAR[ ] pos=60174 blev=0,btyp=L w=8 a+d=12+3 MB 13 104: CHAR[c] pos=60175 blev=0,btyp=L w=8 a+d=12+3 MB 14 112: CHAR[)] pos=60176 blev=0,btyp=L w=8 a+d=12+3 MB 15 120: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=12+3 MB (gdb) p a->hash $3 = 127343105 (gdb) p b->hash $4 = 127343105 (gdb) ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-15 17:12 ` Juanma Barranquero @ 2011-11-15 18:00 ` Eli Zaretskii 2011-11-15 19:19 ` Juanma Barranquero 0 siblings, 1 reply; 36+ messages in thread From: Eli Zaretskii @ 2011-11-15 18:00 UTC (permalink / raw) To: Juanma Barranquero; +Cc: cschol2112, 10035 > From: Juanma Barranquero <lekktu@gmail.com> > Date: Tue, 15 Nov 2011 18:12:47 +0100 > Cc: Christoph Scholtes <cschol2112@googlemail.com>, 10035@debbugs.gnu.org > > I just had another assertion failure in row_equal_p, which seems a > variant of the bug you fixed. In this case, "pgrowx a" and "pgrowx b" > do not show the same content, but a->hash == b->hash. Two different rows having the same hash is not a problem -- the hash function isn't guaranteed to be perfect. The problem is that at least one of the hash values does not match the contents of its glyph row. > I was just editing elisp code, and the assertion failure happened > during an isearch for "lets". The offending row is `a'. Is the text it shows ("Slot is the name") a comment, displayed in font-lock-comment-face? Can you show a screenshot? > #2 0x0107bb11 in row_equal_p (b=0x373e968, a=0x5d4f968, > mouse_face_p=<optimized out>) at dispnew.c:1294 ^^^^^^^^^^^^^^^ ??? Does GCC now optimizes even under -O0? ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-15 18:00 ` Eli Zaretskii @ 2011-11-15 19:19 ` Juanma Barranquero 2011-11-15 20:20 ` Eli Zaretskii 0 siblings, 1 reply; 36+ messages in thread From: Juanma Barranquero @ 2011-11-15 19:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cschol2112, 10035 [-- Attachment #1: Type: text/plain, Size: 351 bytes --] On Tue, Nov 15, 2011 at 19:00, Eli Zaretskii <eliz@gnu.org> wrote: > The offending row is `a'. Is the text it shows ("Slot is the name") a > comment, displayed in font-lock-comment-face? Can you show a > screenshot? Attached. > ??? Does GCC now optimizes even under -O0? This happened with an optimized build, alas. Juanma [-- Attachment #2: bug.png --] [-- Type: image/png, Size: 151238 bytes --] ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-15 19:19 ` Juanma Barranquero @ 2011-11-15 20:20 ` Eli Zaretskii 2011-11-15 20:28 ` Juanma Barranquero 0 siblings, 1 reply; 36+ messages in thread From: Eli Zaretskii @ 2011-11-15 20:20 UTC (permalink / raw) To: Juanma Barranquero; +Cc: cschol2112, 10035 > From: Juanma Barranquero <lekktu@gmail.com> > Date: Tue, 15 Nov 2011 20:19:52 +0100 > Cc: cschol2112@googlemail.com, 10035@debbugs.gnu.org > > On Tue, Nov 15, 2011 at 19:00, Eli Zaretskii <eliz@gnu.org> wrote: > > > The offending row is `a'. Is the text it shows ("Slot is the name") a > > comment, displayed in font-lock-comment-face? Can you show a > > screenshot? > > Attached. Thanks. So row `a' is a part of this line: Slot is the name of the slot when created by `defclass' or the label truncated to have the same number of glyphs as row `b'. Hmm... Is this crash easily reproducible? I tried I-searching eieio.el in "emacs -Q", after setting scroll-conservatively to a large value, but Emacs didn't crash. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-15 20:20 ` Eli Zaretskii @ 2011-11-15 20:28 ` Juanma Barranquero 2011-11-16 3:45 ` Eli Zaretskii 2011-11-16 23:13 ` Juanma Barranquero 0 siblings, 2 replies; 36+ messages in thread From: Juanma Barranquero @ 2011-11-15 20:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cschol2112, 10035 On Tue, Nov 15, 2011 at 21:20, Eli Zaretskii <eliz@gnu.org> wrote: > Is this crash easily reproducible? I don't think so. I was editing elisp files and using isearch for at least one hour or so before it crashed. I'll switch to run the non-optimized build under gdb, and hope for a bit of luck. Do you need the running session or can I close it? Juanma ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-15 20:28 ` Juanma Barranquero @ 2011-11-16 3:45 ` Eli Zaretskii 2011-11-16 23:13 ` Juanma Barranquero 1 sibling, 0 replies; 36+ messages in thread From: Eli Zaretskii @ 2011-11-16 3:45 UTC (permalink / raw) To: Juanma Barranquero; +Cc: cschol2112, 10035 > From: Juanma Barranquero <lekktu@gmail.com> > Date: Tue, 15 Nov 2011 21:28:23 +0100 > Cc: cschol2112@googlemail.com, 10035@debbugs.gnu.org > > Do you need the running session or can I close it? You can close it. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-15 20:28 ` Juanma Barranquero 2011-11-16 3:45 ` Eli Zaretskii @ 2011-11-16 23:13 ` Juanma Barranquero 2011-11-17 3:56 ` Eli Zaretskii 1 sibling, 1 reply; 36+ messages in thread From: Juanma Barranquero @ 2011-11-16 23:13 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cschol2112, 10035 On Tue, Nov 15, 2011 at 21:28, Juanma Barranquero <lekktu@gmail.com> wrote: > I'll switch to run the > non-optimized build under gdb, and hope for a bit of luck. A bit of luck. I can reproduce it. Let's see whether you can, too. File test.el contains this (not including bracketing lines): -------------------------------------------------------------------------------- (require 'bs) (global-set-key [s-f9] 'bs-cycle-previous) (global-set-key [f9] 'bs-cycle-next) -------------------------------------------------------------------------------- and from the src/ directory I run gdb -ex run --args ..\bin\emacs.exe -Q -l test.el blockinput.h w32term.c w32inevt.c then C-x 1 ; to remove the buffer list window <f9> <s-f9> ; or <s-f9> <f9> Juanma ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-16 23:13 ` Juanma Barranquero @ 2011-11-17 3:56 ` Eli Zaretskii 2011-11-18 4:17 ` Christoph Scholtes 2011-11-18 12:27 ` Eli Zaretskii 0 siblings, 2 replies; 36+ messages in thread From: Eli Zaretskii @ 2011-11-17 3:56 UTC (permalink / raw) To: Juanma Barranquero; +Cc: cschol2112, 10035 > From: Juanma Barranquero <lekktu@gmail.com> > Date: Thu, 17 Nov 2011 00:13:56 +0100 > Cc: cschol2112@googlemail.com, 10035@debbugs.gnu.org > > (require 'bs) > (global-set-key [s-f9] 'bs-cycle-previous) > (global-set-key [f9] 'bs-cycle-next) > -------------------------------------------------------------------------------- > > and from the src/ directory I run > > gdb -ex run --args ..\bin\emacs.exe -Q -l test.el blockinput.h > w32term.c w32inevt.c > > then > > C-x 1 ; to remove the buffer list window > <f9> <s-f9> ; or <s-f9> <f9> Reproduced, thanks. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-17 3:56 ` Eli Zaretskii @ 2011-11-18 4:17 ` Christoph Scholtes 2011-11-18 7:08 ` Eli Zaretskii 2011-11-18 12:27 ` Eli Zaretskii 1 sibling, 1 reply; 36+ messages in thread From: Christoph Scholtes @ 2011-11-18 4:17 UTC (permalink / raw) To: Eli Zaretskii; +Cc: Juanma Barranquero, 10035 I had two more `row_equal_p' crashes today when browsing C code. This is with Mondays build r106380. I can provide backtraces tomorrow, but I don't have a debug setup on this machine. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-18 4:17 ` Christoph Scholtes @ 2011-11-18 7:08 ` Eli Zaretskii 0 siblings, 0 replies; 36+ messages in thread From: Eli Zaretskii @ 2011-11-18 7:08 UTC (permalink / raw) To: Christoph Scholtes; +Cc: lekktu, 10035 > Date: Thu, 17 Nov 2011 21:17:47 -0700 > From: Christoph Scholtes <cschol2112@googlemail.com> > CC: Juanma Barranquero <lekktu@gmail.com>, 10035@debbugs.gnu.org > > I had two more `row_equal_p' crashes today when browsing C code. > > This is with Mondays build r106380. I can provide backtraces tomorrow, > but I don't have a debug setup on this machine. Please provide backtraces, and also how to reproduce, if you know that. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-17 3:56 ` Eli Zaretskii 2011-11-18 4:17 ` Christoph Scholtes @ 2011-11-18 12:27 ` Eli Zaretskii 2011-11-18 13:00 ` Juanma Barranquero 1 sibling, 1 reply; 36+ messages in thread From: Eli Zaretskii @ 2011-11-18 12:27 UTC (permalink / raw) To: lekktu, cschol2112; +Cc: 10035 > Date: Thu, 17 Nov 2011 05:56:25 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: cschol2112@googlemail.com, 10035@debbugs.gnu.org > > > From: Juanma Barranquero <lekktu@gmail.com> > > Date: Thu, 17 Nov 2011 00:13:56 +0100 > > Cc: cschol2112@googlemail.com, 10035@debbugs.gnu.org > > > > (require 'bs) > > (global-set-key [s-f9] 'bs-cycle-previous) > > (global-set-key [f9] 'bs-cycle-next) > > -------------------------------------------------------------------------------- > > > > and from the src/ directory I run > > > > gdb -ex run --args ..\bin\emacs.exe -Q -l test.el blockinput.h > > w32term.c w32inevt.c > > > > then > > > > C-x 1 ; to remove the buffer list window > > <f9> <s-f9> ; or <s-f9> <f9> > > Reproduced, thanks. I fixed the bug that caused this recipe to crash (revision 106411 on the trunk). I hope it also fixes the crashes experienced by Christoph. Note that the crash Juanma reported in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10035#79 shows a call-stack that is different from the one produced by the above recipe. So I hope that, too, is fixed. ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-18 12:27 ` Eli Zaretskii @ 2011-11-18 13:00 ` Juanma Barranquero 0 siblings, 0 replies; 36+ messages in thread From: Juanma Barranquero @ 2011-11-18 13:00 UTC (permalink / raw) To: Eli Zaretskii; +Cc: cschol2112, 10035 On Fri, Nov 18, 2011 at 13:27, Eli Zaretskii <eliz@gnu.org> wrote: > Note that the crash Juanma reported in > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10035#79 > > shows a call-stack that is different from the one produced by the > above recipe. So I hope that, too, is fixed. Well, the crash in #79 is not reproducible, so if it is a different bug, we'll know sooner or later. Thanks, Juanma ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-13 20:21 ` Eli Zaretskii 2011-11-13 20:42 ` Juanma Barranquero @ 2011-11-13 20:55 ` Christoph Scholtes 2011-11-14 3:55 ` Eli Zaretskii 1 sibling, 1 reply; 36+ messages in thread From: Christoph Scholtes @ 2011-11-13 20:55 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 10035 On 11/13/2011 1:21 PM, Eli Zaretskii wrote: > Sorry, I meant to type this in frame #2, where a and be are arguments > of the function row_equal_p: > >> #2 0x010ee0d5 in row_equal_p (a=0x10dc2158, b=0x10d97158, mouse_face_p=1) >> at dispnew.c:398 (gdb) p a->enabled_p $2 = 1 (gdb) p b->enabled_p $3 = 1 > Btw, what's up with the messed up line numbers in dispnew.c? Observe: > > #2 0x010ee0d5 in row_equal_p (a=0x10dc2158, b=0x10d97158, mouse_face_p=1) > at dispnew.c:398 > #3 0x010f490f in scrolling_window (w=0x10d96000, header_line_p=0) > at dispnew.c:398 > #4 0x010f30fe in update_window (w=0x10d96000, force_p=1) at dispnew.c:398 > #5 0x010f27fe in update_window_tree (w=0x10d96000, force_p=1) > at dispnew.c:398 > #6 0x010f27d7 in update_window_tree (w=0x10d72200, force_p=1) > at dispnew.c:398 > #7 0x010f254d in update_frame (f=0x3a24e00, force_p=1, inhibit_hairy_id_p=0) > at dispnew.c:398 > > We are obviously very smart if we succeeded to squeeze all these > functions into a single source line ;-) Interesting. I didn't notice that. > What version of GCC is that? tdm-gcc 4.6.1 ^ permalink raw reply [flat|nested] 36+ messages in thread
* bug#10035: Crash in check_x_frame in w32fns.c 2011-11-13 20:55 ` Christoph Scholtes @ 2011-11-14 3:55 ` Eli Zaretskii 0 siblings, 0 replies; 36+ messages in thread From: Eli Zaretskii @ 2011-11-14 3:55 UTC (permalink / raw) To: Christoph Scholtes; +Cc: 10035 > Date: Sun, 13 Nov 2011 13:55:30 -0700 > From: Christoph Scholtes <cschol2112@googlemail.com> > CC: 10035@debbugs.gnu.org > > On 11/13/2011 1:21 PM, Eli Zaretskii wrote: > > > Sorry, I meant to type this in frame #2, where a and be are arguments > > of the function row_equal_p: > > > >> #2 0x010ee0d5 in row_equal_p (a=0x10dc2158, b=0x10d97158, mouse_face_p=1) > >> at dispnew.c:398 > > (gdb) p a->enabled_p > $2 = 1 > (gdb) p b->enabled_p > $3 = 1 Good. Now let's see what are these two glyph rows: (gdb) prowx a (gdb) prowx b (gdb) pgrowx a (gdb) pgrowx b The last two commands will display all the display elements (characters, references to images and display strings, etc.) in each glyph row. Assuming it is not a total garbage, please try to describe what happened on the screen around these glyph rows (== screen lines). A bit of a background: scrolling_window, the function that called row_equal_p, is comparing the previous and the new contents of a window, trying to figure out which screen lines need to be redrawn and which can be reused from the previous redisplay cycle. row_equal_p is the comparison function. So one of the glyph rows should be from the window before some update, the other glyph row is from the new contents of the window. They could be identical or they could be different. > > #2 0x010ee0d5 in row_equal_p (a=0x10dc2158, b=0x10d97158, mouse_face_p=1) > > at dispnew.c:398 > > #3 0x010f490f in scrolling_window (w=0x10d96000, header_line_p=0) > > at dispnew.c:398 > > #4 0x010f30fe in update_window (w=0x10d96000, force_p=1) at dispnew.c:398 > > #5 0x010f27fe in update_window_tree (w=0x10d96000, force_p=1) > > at dispnew.c:398 > > #6 0x010f27d7 in update_window_tree (w=0x10d72200, force_p=1) > > at dispnew.c:398 > > #7 0x010f254d in update_frame (f=0x3a24e00, force_p=1, inhibit_hairy_id_p=0) > > at dispnew.c:398 > > > > We are obviously very smart if we succeeded to squeeze all these > > functions into a single source line ;-) > > Interesting. I didn't notice that. > > > What version of GCC is that? > > tdm-gcc 4.6.1 If this is an unoptimized build, this shouldn't happen, and perhaps it's a compiler bug. Or maybe GCC 4.6 does some optimizations even with -O0. ^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2011-11-18 13:00 UTC | newest] Thread overview: 36+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-11-13 15:29 bug#10035: Crash in check_x_frame in w32fns.c Christoph Scholtes 2011-11-13 17:18 ` Eli Zaretskii 2011-11-13 20:04 ` Christoph Scholtes 2011-11-13 20:21 ` Eli Zaretskii 2011-11-13 20:42 ` Juanma Barranquero 2011-11-14 3:56 ` Eli Zaretskii 2011-11-14 8:57 ` Juanma Barranquero 2011-11-14 11:23 ` Eli Zaretskii 2011-11-14 11:44 ` Juanma Barranquero 2011-11-14 13:35 ` Eli Zaretskii 2011-11-14 14:29 ` Juanma Barranquero 2011-11-14 15:46 ` Juanma Barranquero 2011-11-14 17:19 ` Eli Zaretskii 2011-11-14 17:08 ` Eli Zaretskii 2011-11-14 17:20 ` Juanma Barranquero 2011-11-14 17:32 ` Juanma Barranquero 2011-11-14 17:41 ` Juanma Barranquero 2011-11-14 19:43 ` Eli Zaretskii 2011-11-14 20:18 ` Eli Zaretskii 2011-11-14 21:07 ` Juanma Barranquero 2011-11-15 0:43 ` Christoph Scholtes 2011-11-15 3:48 ` Eli Zaretskii 2011-11-15 17:12 ` Juanma Barranquero 2011-11-15 18:00 ` Eli Zaretskii 2011-11-15 19:19 ` Juanma Barranquero 2011-11-15 20:20 ` Eli Zaretskii 2011-11-15 20:28 ` Juanma Barranquero 2011-11-16 3:45 ` Eli Zaretskii 2011-11-16 23:13 ` Juanma Barranquero 2011-11-17 3:56 ` Eli Zaretskii 2011-11-18 4:17 ` Christoph Scholtes 2011-11-18 7:08 ` Eli Zaretskii 2011-11-18 12:27 ` Eli Zaretskii 2011-11-18 13:00 ` Juanma Barranquero 2011-11-13 20:55 ` Christoph Scholtes 2011-11-14 3:55 ` 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).
![[-- Attachment #2: bug.png --] [-- Type: image/png, Size: 88280 bytes --]](../../CAAeL0STrTGFjeWQ7H6Hoqc+1m-Axtrexm1MnJBtau-Aqx9ZGYQ@mail.gmail.com/2-bug.png){kind=link}
![[-- Attachment #2: bug.png --] [-- Type: image/png, Size: 151238 bytes --]](../../CAAeL0SQ3+EriJDnA-b5hU_YM6K432ii=6aQX3mVRnsmtnBigBA@mail.gmail.com/2-bug.png){kind=link}