GNU bug report logs -
#10035
Crash in check_x_frame in w32fns.c
Previous Next
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 10035 in the body.
You can then email your comments to 10035 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Sun, 13 Nov 2011 15:31:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Christoph Scholtes <cschol2112 <at> googlemail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Sun, 13 Nov 2011 15:31:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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"'
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Sun, 13 Nov 2011 17:21:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 10035 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 13 Nov 2011 08:29:34 -0700
> From: Christoph Scholtes <cschol2112 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Sun, 13 Nov 2011 20:06:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 10035 <at> debbugs.gnu.org (full text, mbox):
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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Sun, 13 Nov 2011 20:25:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 10035 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 13 Nov 2011 13:04:59 -0700
> From: Christoph Scholtes <cschol2112 <at> googlemail.com>
> CC: 10035 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Sun, 13 Nov 2011 20:45:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 10035 <at> debbugs.gnu.org (full text, mbox):
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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Sun, 13 Nov 2011 20:57:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 10035 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Mon, 14 Nov 2011 03:59:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 10035 <at> debbugs.gnu.org (full text, mbox):
> Date: Sun, 13 Nov 2011 13:55:30 -0700
> From: Christoph Scholtes <cschol2112 <at> googlemail.com>
> CC: 10035 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Mon, 14 Nov 2011 04:00:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 10035 <at> debbugs.gnu.org (full text, mbox):
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Sun, 13 Nov 2011 21:42:58 +0100
> Cc: Christoph Scholtes <cschol2112 <at> googlemail.com>, 10035 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Mon, 14 Nov 2011 08:59:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 10035 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Mon, Nov 14, 2011 at 04:56, Eli Zaretskii <eliz <at> 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
[bug.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Mon, 14 Nov 2011 11:24:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 10035 <at> debbugs.gnu.org (full text, mbox):
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Mon, 14 Nov 2011 09:57:17 +0100
> Cc: cschol2112 <at> googlemail.com, 10035 <at> debbugs.gnu.org
>
>
> [1:text/plain Hide]
>
> On Mon, Nov 14, 2011 at 04:56, Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Mon, 14 Nov 2011 11:46:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 10035 <at> debbugs.gnu.org (full text, mbox):
On Mon, Nov 14, 2011 at 12:23, Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Mon, 14 Nov 2011 13:36:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 10035 <at> debbugs.gnu.org (full text, mbox):
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Mon, 14 Nov 2011 12:44:04 +0100
> Cc: cschol2112 <at> googlemail.com, 10035 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Mon, 14 Nov 2011 14:31:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 10035 <at> debbugs.gnu.org (full text, mbox):
On Mon, Nov 14, 2011 at 14:35, Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Mon, 14 Nov 2011 15:48:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 10035 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Mon, 14 Nov 2011 17:11:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 10035 <at> debbugs.gnu.org (full text, mbox):
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Mon, 14 Nov 2011 15:29:00 +0100
> Cc: cschol2112 <at> googlemail.com, 10035 <at> debbugs.gnu.org
>
> On Mon, Nov 14, 2011 at 14:35, Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Mon, 14 Nov 2011 17:22:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 10035 <at> debbugs.gnu.org (full text, mbox):
On Mon, Nov 14, 2011 at 18:08, Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Mon, 14 Nov 2011 17:24:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 10035 <at> debbugs.gnu.org (full text, mbox):
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Mon, 14 Nov 2011 16:46:29 +0100
> Cc: cschol2112 <at> googlemail.com, 10035 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Mon, 14 Nov 2011 17:34:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 10035 <at> debbugs.gnu.org (full text, mbox):
> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Mon, 14 Nov 2011 17:44:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 10035 <at> debbugs.gnu.org (full text, mbox):
On Mon, Nov 14, 2011 at 18:08, Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Mon, 14 Nov 2011 19:47:02 GMT)
Full text and
rfc822 format available.
Message #62 received at 10035 <at> debbugs.gnu.org (full text, mbox):
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Mon, 14 Nov 2011 18:41:54 +0100
> Cc: cschol2112 <at> googlemail.com, 10035 <at> debbugs.gnu.org
>
> On Mon, Nov 14, 2011 at 18:08, Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Mon, 14 Nov 2011 20:22:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 10035 <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 14 Nov 2011 21:43:35 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: cschol2112 <at> googlemail.com, 10035 <at> debbugs.gnu.org
>
> > From: Juanma Barranquero <lekktu <at> gmail.com>
> > Date: Mon, 14 Nov 2011 18:41:54 +0100
> > Cc: cschol2112 <at> googlemail.com, 10035 <at> debbugs.gnu.org
> >
> > On Mon, Nov 14, 2011 at 18:08, Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Mon, 14 Nov 2011 21:09:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 10035 <at> debbugs.gnu.org (full text, mbox):
On Mon, Nov 14, 2011 at 21:18, Eli Zaretskii <eliz <at> gnu.org> wrote:
> This one is fixed (revision 106372 on the trunk). Please check the
> other recipes.
They are all fixed too.
Juanma
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Tue, 15 Nov 2011 00:44:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 10035 <at> debbugs.gnu.org (full text, mbox):
On 11/14/2011 2:07 PM, Juanma Barranquero wrote:
> On Mon, Nov 14, 2011 at 21:18, Eli Zaretskii<eliz <at> 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!
Reply sent
to
Eli Zaretskii <eliz <at> gnu.org>:
You have taken responsibility.
(Tue, 15 Nov 2011 03:52:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Christoph Scholtes <cschol2112 <at> googlemail.com>:
bug acknowledged by developer.
(Tue, 15 Nov 2011 03:52:02 GMT)
Full text and
rfc822 format available.
Message #76 received at 10035-done <at> debbugs.gnu.org (full text, mbox):
> Date: Mon, 14 Nov 2011 17:43:13 -0700
> From: Christoph Scholtes <cschol2112 <at> googlemail.com>
> CC: Eli Zaretskii <eliz <at> gnu.org>, 10035 <at> debbugs.gnu.org
>
> On 11/14/2011 2:07 PM, Juanma Barranquero wrote:
> > On Mon, Nov 14, 2011 at 21:18, Eli Zaretskii<eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Tue, 15 Nov 2011 17:15:02 GMT)
Full text and
rfc822 format available.
Message #79 received at 10035 <at> debbugs.gnu.org (full text, mbox):
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)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Tue, 15 Nov 2011 18:03:01 GMT)
Full text and
rfc822 format available.
Message #82 received at 10035 <at> debbugs.gnu.org (full text, mbox):
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Tue, 15 Nov 2011 18:12:47 +0100
> Cc: Christoph Scholtes <cschol2112 <at> googlemail.com>, 10035 <at> 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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Tue, 15 Nov 2011 19:22:02 GMT)
Full text and
rfc822 format available.
Message #85 received at 10035 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Nov 15, 2011 at 19:00, Eli Zaretskii <eliz <at> 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
[bug.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Tue, 15 Nov 2011 20:24:01 GMT)
Full text and
rfc822 format available.
Message #88 received at 10035 <at> debbugs.gnu.org (full text, mbox):
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Tue, 15 Nov 2011 20:19:52 +0100
> Cc: cschol2112 <at> googlemail.com, 10035 <at> debbugs.gnu.org
>
> On Tue, Nov 15, 2011 at 19:00, Eli Zaretskii <eliz <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Tue, 15 Nov 2011 20:30:02 GMT)
Full text and
rfc822 format available.
Message #91 received at 10035 <at> debbugs.gnu.org (full text, mbox):
On Tue, Nov 15, 2011 at 21:20, Eli Zaretskii <eliz <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Wed, 16 Nov 2011 03:49:02 GMT)
Full text and
rfc822 format available.
Message #94 received at 10035 <at> debbugs.gnu.org (full text, mbox):
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Tue, 15 Nov 2011 21:28:23 +0100
> Cc: cschol2112 <at> googlemail.com, 10035 <at> debbugs.gnu.org
>
> Do you need the running session or can I close it?
You can close it.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Wed, 16 Nov 2011 23:16:01 GMT)
Full text and
rfc822 format available.
Message #97 received at 10035 <at> debbugs.gnu.org (full text, mbox):
On Tue, Nov 15, 2011 at 21:28, Juanma Barranquero <lekktu <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Thu, 17 Nov 2011 04:00:02 GMT)
Full text and
rfc822 format available.
Message #100 received at 10035 <at> debbugs.gnu.org (full text, mbox):
> From: Juanma Barranquero <lekktu <at> gmail.com>
> Date: Thu, 17 Nov 2011 00:13:56 +0100
> Cc: cschol2112 <at> googlemail.com, 10035 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Fri, 18 Nov 2011 04:19:02 GMT)
Full text and
rfc822 format available.
Message #103 received at 10035 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Fri, 18 Nov 2011 07:12:01 GMT)
Full text and
rfc822 format available.
Message #106 received at 10035 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 17 Nov 2011 21:17:47 -0700
> From: Christoph Scholtes <cschol2112 <at> googlemail.com>
> CC: Juanma Barranquero <lekktu <at> gmail.com>, 10035 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Fri, 18 Nov 2011 12:31:01 GMT)
Full text and
rfc822 format available.
Message #109 received at 10035 <at> debbugs.gnu.org (full text, mbox):
> Date: Thu, 17 Nov 2011 05:56:25 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: cschol2112 <at> googlemail.com, 10035 <at> debbugs.gnu.org
>
> > From: Juanma Barranquero <lekktu <at> gmail.com>
> > Date: Thu, 17 Nov 2011 00:13:56 +0100
> > Cc: cschol2112 <at> googlemail.com, 10035 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#10035; Package
emacs.
(Fri, 18 Nov 2011 13:03:01 GMT)
Full text and
rfc822 format available.
Message #112 received at 10035 <at> debbugs.gnu.org (full text, mbox):
On Fri, Nov 18, 2011 at 13:27, Eli Zaretskii <eliz <at> 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
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Sat, 17 Dec 2011 12:24:02 GMT)
Full text and
rfc822 format available.
This bug report was last modified 12 years and 158 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.