* emacs-21.1.94 crash in gnus on Windows
@ 2010-03-15 23:40 Andy Moreton
2010-03-16 10:33 ` Eli Zaretskii
0 siblings, 1 reply; 20+ messages in thread
From: Andy Moreton @ 2010-03-15 23:40 UTC (permalink / raw)
To: emacs-devel
Hi,
I've built 21.1.94 pretest on WinXP SP3 with MinGW gcc, and I'm seeing
a repeatable crash in gnus. Running emacs under gdb I managed to capture
a crash, with the following results:
Program received signal SIGSEGV, Segmentation fault.
0x0102ef33 in pos_visible_p (w=0x2fa6e00, charpos=0x22fa, x=0x82eef8, y=0x82eef4, rtop=0x82ef08,
rbot=0x82ef04, rowh=0x82ef00, vpos=0x82eefc) at xdisp.c:1397
1397 && (!BUFFERP (glyph->object)
(gdb) warning: frame 02FA6400 (emacs@aji *Group*) obscured
warning: obscured frame 02FA6400 (emacs@aji *Group*) found to be visible
bt
#0 0x0102ef33 in pos_visible_p (w=0x2fa6e00, charpos=0x22fa, x=0x82eef8, y=0x82eef4,
rtop=0x82ef08, rbot=0x82ef04, rowh=0x82ef00, vpos=0x82eefc) at xdisp.c:1397
#1 0x010f62d8 in Fpos_visible_in_window_p (pos=0x8be8, window=0x2fa6e05, partially=0x2ba7802)
at window.c:357
#2 0x010228b1 in Ffuncall (nargs=0x3, args=0x82f010) at eval.c:3030
#3 0x01113471 in Fbyte_code (bytestr=0x3904201, vector=0x3aacc05, maxdepth=0x10) at bytecode.c:680
#4 0x01022fae in funcall_lambda (fun=0x3ab08c5, nargs=0x0, arg_vector=0x82f2c8) at eval.c:3211
#5 0x01022a86 in Ffuncall (nargs=0x1, args=0x82f2c4) at eval.c:3070
#6 0x01113471 in Fbyte_code (bytestr=0x39182e1, vector=0x3aac405, maxdepth=0x10) at bytecode.c:680
#7 0x01022fae in funcall_lambda (fun=0x3ab6125, nargs=0x1, arg_vector=0x82f574) at eval.c:3211
#8 0x01022a86 in Ffuncall (nargs=0x2, args=0x82f570) at eval.c:3070
#9 0x01113471 in Fbyte_code (bytestr=0x3ab7831, vector=0x3abad05, maxdepth=0x14) at bytecode.c:680
#10 0x01022fae in funcall_lambda (fun=0x3abbae5, nargs=0x1, arg_vector=0x82f884) at eval.c:3211
#11 0x01022a86 in Ffuncall (nargs=0x2, args=0x82f880) at eval.c:3070
#12 0x01117b8a in Fcall_interactively (function=0x3a6f6d2, record_flag=0x2ba7802, keys=0x2bacb05)
at callint.c:869
#13 0x010228b1 in Ffuncall (nargs=0x4, args=0x82fb50) at eval.c:3030
#14 0x0102244f in call3 (fn=0x2bcc5ca, arg1=0x3a6f6d2, arg2=0x2ba7802, arg3=0x2ba7802)
at eval.c:2850
#15 0x01014d20 in Fcommand_execute (cmd=0x3a6f6d2, record_flag=0x2ba7802, keys=0x2ba7802,
special=0x2ba7802) at keyboard.c:10507
#16 0x010076b0 in command_loop_1 () at keyboard.c:1904
#17 0x01020549 in internal_condition_case (bfun=0x100625a <command_loop_1>, handlers=0x2bb54da,
hfun=0x1005c3b <cmd_error>) at eval.c:1490
#18 0x01005fb3 in command_loop_2 () at keyboard.c:1360
#19 0x0102009a in internal_catch (tag=0x2bb51b2, func=0x1005f8e <command_loop_2>, arg=0x2ba7802)
at eval.c:1226
#20 0x01005f6c in command_loop () at keyboard.c:1339
#21 0x0100585e in recursive_edit_1 () at keyboard.c:954
#22 0x010059c7 in Frecursive_edit () at keyboard.c:1016
#23 0x010028c5 in main (argc=0x1, argv=0xa44418) at emacs.c:1833
Lisp Backtrace:
"pos-visible-in-window-p" (0x82f014)
"gnus-summary-recenter" (0x82f2c8)
"gnus-summary-display-article" (0x82f574)
"gnus-summary-next-page" (0x82f884)
"call-interactively" (0x82fb54)
(gdb)
Please let me know what other info/testing is needed to help fix this.
AndyM
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: emacs-21.1.94 crash in gnus on Windows
2010-03-15 23:40 emacs-21.1.94 crash in gnus on Windows Andy Moreton
@ 2010-03-16 10:33 ` Eli Zaretskii
2010-03-16 12:53 ` Andy Moreton
0 siblings, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2010-03-16 10:33 UTC (permalink / raw)
To: Andy Moreton; +Cc: emacs-devel
> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Mon, 15 Mar 2010 23:40:27 +0000
>
> I've built 21.1.94 pretest on WinXP SP3 with MinGW gcc, and I'm seeing
> a repeatable crash in gnus. Running emacs under gdb I managed to capture
> a crash, with the following results:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x0102ef33 in pos_visible_p (w=0x2fa6e00, charpos=0x22fa, x=0x82eef8, y=0x82eef4, rtop=0x82ef08,
> rbot=0x82ef04, rowh=0x82ef00, vpos=0x82eefc) at xdisp.c:1397
> 1397 && (!BUFFERP (glyph->object)
Thank you for your report.
> Please let me know what other info/testing is needed to help fix this.
First, please file a bug report with this information.
Second, please type "bt full" and post the results.
Third, if this is an optimized build, please build Emacs without
optimizations, and when the crash happens again, please type "bt full"
and send the results.
Finally, could you tell what kind of text is at character position
(in this case, 0x22fa) with which pos_visible_p is called when it
crashes? Are there any unusual text properties there, like invisible
text, ellipsis (which stands for hidden text), or something similar?
Thanks.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: emacs-21.1.94 crash in gnus on Windows
2010-03-16 10:33 ` Eli Zaretskii
@ 2010-03-16 12:53 ` Andy Moreton
2010-03-16 15:26 ` David Kastrup
2010-03-16 19:47 ` Eli Zaretskii
0 siblings, 2 replies; 20+ messages in thread
From: Andy Moreton @ 2010-03-16 12:53 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel
On 16/03/2010 10:33, Eli Zaretskii wrote:
>> From: Andy Moreton<andrewjmoreton@gmail.com>
>> Date: Mon, 15 Mar 2010 23:40:27 +0000
>>
>> I've built 21.1.94 pretest on WinXP SP3 with MinGW gcc, and I'm seeing
>> a repeatable crash in gnus. Running emacs under gdb I managed to capture
>> a crash, with the following results:
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x0102ef33 in pos_visible_p (w=0x2fa6e00, charpos=0x22fa, x=0x82eef8, y=0x82eef4, rtop=0x82ef08,
>> rbot=0x82ef04, rowh=0x82ef00, vpos=0x82eefc) at xdisp.c:1397
>> 1397&& (!BUFFERP (glyph->object)
>
> Thank you for your report.
>
>> Please let me know what other info/testing is needed to help fix this.
>
> First, please file a bug report with this information.
I've sent a bug report (from another machine after recreating the crash).
> Second, please type "bt full" and post the results.
>
> Third, if this is an optimized build, please build Emacs without
> optimizations, and when the crash happens again, please type "bt full"
> and send the results.
>
> Finally, could you tell what kind of text is at character position
> (in this case, 0x22fa) with which pos_visible_p is called when it
> crashes? Are there any unusual text properties there, like invisible
> text, ellipsis (which stands for hidden text), or something similar?
emacs was configured on both machines with "--no-opt". I've added details of
the crash in the bug report below.
Program received signal SIGSEGV, Segmentation fault.
0x01030355 in pos_visible_p (w=0x307c800, charpos=0x5ad, x=0x82f0c4,
y=0x82f0c0, rtop=0x82f0d8,
rbot=0x82f0d4, rowh=0x82f0d0, vpos=0x82f0cc) at xdisp.c:1396
1396 for (; glyph < end
(gdb) warning: reader_thread.SetEvent failed with 6 for fd -1
warning: reader_thread.SetEvent failed with 6 for fd -1
warning: reader_thread.SetEvent failed with 6 for fd -1
warning: reader_thread.SetEvent failed with 6 for fd -1
warning: reader_thread.SetEvent failed with 6 for fd -1
bt full
Reading in symbols for window.c...done.
Reading in symbols for eval.c...done.
Reading in symbols for bytecode.c...done.
Reading in symbols for callint.c...done.
Reading in symbols for keyboard.c...done.
#0 0x01030355 in pos_visible_p (w=0x307c800, charpos=0x5ad, x=0x82f0c4,
y=0x82f0c0,
rtop=0x82f0d8, rbot=0x82f0d4, rowh=0x82f0d0, vpos=0x82f0cc) at xdisp.c:1396
row = 0x380a098
glyph = 0x38d0020
end = 0x38d0ea0
x = 0x0
window = 0x307c805
prop = 0x33fb62a
top_y = 0x62
it_method = GET_FROM_BUFFER
window_top_y = 0xe
top_x = 0x333
bottom_y = 0x70
it = {
window = 0x307c805,
w = 0x307c800,
f = 0x307c000,
method = GET_FROM_BUFFER,
stop_charpos = 0x719,
end_charpos = 0x719,
s = 0x0,
string_nchars = 0x0,
region_beg_charpos = 0xffffffff,
region_end_charpos = 0xffffffff,
redisplay_end_trigger_charpos = 0x0,
multibyte_p = 0x1,
header_line_p = 0x1,
string_from_display_prop_p = 0x0,
ellipsis_p = 0x0,
avoid_cursor_p = 0x0,
dp = 0x48b4e00,
dpvec = 0x0,
dpend = 0x13da13c,
dpvec_char_len = 0x0,
dpvec_face_id = 0xffffffff,
saved_face_id = 0x0,
ctl_chars = {0x0 <repeats 16 times>},
start = {
pos = {
charpos = 0x1,
bytepos = 0x1
},
overlay_string_index = 0xffffffff,
string_pos = {
charpos = 0xffffffff,
bytepos = 0xffffffff
},
dpvec_index = 0xffffffff
},
current = {
pos = {
charpos = 0x719,
bytepos = 0x759
},
overlay_string_index = 0xffffffff,
string_pos = {
charpos = 0xffffffff,
bytepos = 0xffffffff
},
dpvec_index = 0xffffffff
},
n_overlay_strings = 0x0,
overlay_strings = {0x0 <repeats 16 times>},
string_overlays = {0x0 <repeats 16 times>},
string = 0x2b36802,
from_overlay = 0x0,
stack = {{
string = 0x0,
string_nchars = 0x0,
end_charpos = 0x0,
stop_charpos = 0x0,
cmp_it = {
stop_pos = 0x0,
id = 0x0,
ch = 0x0,
lookback = 0x0,
nglyphs = 0x0,
nchars = 0x0,
nbytes = 0x0,
from = 0x0,
to = 0x0,
width = 0x0
},
face_id = 0x0,
u = {
image = {
object = 0x0,
slice = {
x = 0x0,
y = 0x0,
width = 0x0,
height = 0x0
},
image_id = 0x0
},
comp = {
object = 0x0
},
stretch = {
object = 0x0
}
},
position = {
charpos = 0x0,
bytepos = 0x0
},
current = {
pos = {
charpos = 0x0,
bytepos = 0x0
},
overlay_string_index = 0x0,
string_pos = {
charpos = 0x0,
bytepos = 0x0
},
dpvec_index = 0x0
},
from_overlay = 0x0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
multibyte_p = 0x0,
string_from_display_prop_p = 0x0,
display_ellipsis_p = 0x0,
avoid_cursor_p = 0x0,
line_wrap = TRUNCATE,
voffset = 0x0,
space_width = 0x0,
font_height = 0x0
}, {
string = 0x0,
string_nchars = 0x0,
end_charpos = 0x0,
stop_charpos = 0x0,
cmp_it = {
stop_pos = 0x0,
id = 0x0,
ch = 0x0,
lookback = 0x0,
nglyphs = 0x0,
nchars = 0x0,
nbytes = 0x0,
from = 0x0,
to = 0x0,
width = 0x0
},
face_id = 0x0,
u = {
image = {
object = 0x0,
slice = {
x = 0x0,
y = 0x0,
width = 0x0,
height = 0x0
},
image_id = 0x0
},
comp = {
object = 0x0
},
stretch = {
object = 0x0
}
},
position = {
charpos = 0x0,
bytepos = 0x0
},
current = {
pos = {
charpos = 0x0,
bytepos = 0x0
},
overlay_string_index = 0x0,
string_pos = {
charpos = 0x0,
bytepos = 0x0
},
dpvec_index = 0x0
},
from_overlay = 0x0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
multibyte_p = 0x0,
string_from_display_prop_p = 0x0,
display_ellipsis_p = 0x0,
avoid_cursor_p = 0x0,
line_wrap = TRUNCATE,
voffset = 0x0,
space_width = 0x0,
font_height = 0x0
}, {
string = 0x0,
string_nchars = 0x0,
end_charpos = 0x0,
stop_charpos = 0x0,
cmp_it = {
stop_pos = 0x0,
id = 0x0,
ch = 0x0,
lookback = 0x0,
nglyphs = 0x0,
nchars = 0x0,
nbytes = 0x0,
from = 0x0,
to = 0x0,
width = 0x0
},
face_id = 0x0,
u = {
image = {
object = 0x0,
slice = {
x = 0x0,
y = 0x0,
width = 0x0,
height = 0x0
},
image_id = 0x0
},
comp = {
object = 0x0
},
stretch = {
object = 0x0
}
},
position = {
charpos = 0x0,
bytepos = 0x0
},
current = {
pos = {
charpos = 0x0,
bytepos = 0x0
},
overlay_string_index = 0x0,
string_pos = {
charpos = 0x0,
bytepos = 0x0
},
dpvec_index = 0x0
},
from_overlay = 0x0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
multibyte_p = 0x0,
string_from_display_prop_p = 0x0,
display_ellipsis_p = 0x0,
avoid_cursor_p = 0x0,
line_wrap = TRUNCATE,
voffset = 0x0,
space_width = 0x0,
font_height = 0x0
}, {
string = 0x0,
string_nchars = 0x0,
end_charpos = 0x0,
stop_charpos = 0x0,
cmp_it = {
stop_pos = 0x0,
id = 0x0,
ch = 0x0,
lookback = 0x0,
nglyphs = 0x0,
nchars = 0x0,
nbytes = 0x0,
from = 0x0,
to = 0x0,
width = 0x0
},
face_id = 0x0,
u = {
image = {
object = 0x0,
slice = {
x = 0x0,
y = 0x0,
width = 0x0,
height = 0x0
},
image_id = 0x0
},
comp = {
object = 0x0
},
stretch = {
object = 0x0
}
},
position = {
charpos = 0x0,
bytepos = 0x0
},
current = {
pos = {
charpos = 0x0,
bytepos = 0x0
},
overlay_string_index = 0x0,
string_pos = {
charpos = 0x0,
bytepos = 0x0
},
dpvec_index = 0x0
},
from_overlay = 0x0,
area = LEFT_MARGIN_AREA,
method = GET_FROM_BUFFER,
multibyte_p = 0x0,
string_from_display_prop_p = 0x0,
display_ellipsis_p = 0x0,
avoid_cursor_p = 0x0,
line_wrap = TRUNCATE,
voffset = 0x0,
space_width = 0x0,
font_height = 0x0
}},
sp = 0x0,
selective = 0x0,
what = IT_CHARACTER,
face_id = 0x0,
selective_display_ellipsis_p = 0x0,
ctl_arrow_p = 0x1,
face_box_p = 0x0,
start_of_box_run_p = 0x0,
end_of_box_run_p = 0x0,
overlay_strings_at_end_processed_p = 0x0,
ignore_overlay_strings_at_pos_p = 0x0,
glyph_not_available_p = 0x0,
starts_in_middle_of_char_p = 0x0,
face_before_selective_p = 0x0,
constrain_row_ascent_descent_p = 0x0,
line_wrap = TRUNCATE,
base_face_id = 0x0,
c = 0xa,
len = 0x1,
cmp_it = {
stop_pos = 0x719,
id = 0xffffffff,
ch = 0xfffffffe,
lookback = 0x0,
nglyphs = 0x0,
nchars = 0x0,
nbytes = 0x0,
from = 0x0,
to = 0x0,
width = 0x0
},
char_to_display = 0x20,
image_id = 0x0,
slice = {
x = 0x2b36802,
y = 0x2b36802,
width = 0x2b36802,
height = 0x2b36802
},
space_width = 0x2b36802,
voffset = 0x0,
tab_width = 0x8,
font_height = 0x2b36802,
object = 0x48b4005,
position = {
charpos = 0x718,
bytepos = 0x758
},
truncation_pixel_width = 0x0,
continuation_pixel_width = 0x0,
first_visible_x = 0x0,
last_visible_x = 0x333,
last_visible_y = 0x134,
extra_line_spacing = 0x0,
max_extra_line_spacing = 0x0,
override_ascent = 0xffffffff,
override_descent = 0x0,
override_boff = 0x0,
glyph_row = 0x380a098,
area = TEXT_AREA,
nglyphs = 0x1,
pixel_width = 0x7,
ascent = 0xb,
descent = 0x3,
max_ascent = 0xb,
max_descent = 0x3,
phys_ascent = 0xb,
phys_descent = 0x3,
max_phys_ascent = 0xb,
max_phys_descent = 0x3,
current_x = 0x333,
continuation_lines_width = 0x0,
current_y = 0x62,
first_vpos = 0x1,
vpos = 0x6,
hpos = 0x75,
left_user_fringe_bitmap = 0x0,
right_user_fringe_bitmap = 0x0,
left_user_fringe_face_id = 0x0,
right_user_fringe_face_id = 0x0
}
top = {
charpos = 0x1,
bytepos = 0x1
}
visible_p = 0x1
old_buffer = 0x0
#1 0x010d0859 in Fpos_visible_in_window_p (pos=0x16b4, window=0x307c805,
partially=0x2b36802)
at window.c:352
w = 0x307c800
posint = 0x5ad
buf = 0x48b4000
top = {
charpos = 0x1,
bytepos = 0x1
}
in_window = 0x2b36802
rtop = 0x48b4000
rbot = 0x2b6d0f0
rowh = 0x2b638c2
vpos = 0x119bf77
fully_p = 0x1
x = 0x1
y = 0x48b4000
#2 0x010234f7 in Ffuncall (nargs=0x3, args=0x82f1b0) at eval.c:3030
fun = 0x138e5fd
original_fun = 0x2b69c92
funcar = 0x1
numargs = 0x2
lisp_numargs = 0x10a6d98
val = 0x4
backtrace = {
next = 0x82f380,
function = 0x82f1b0,
args = 0x82f1b4,
nargs = 0x2,
evalargs = 0x0,
debug_on_exit = 0x0
}
internal_args = 0x82f110
i = 0x3
#3 0x0116962f in Fbyte_code (bytestr=0x37e15b1, vector=0x3988605,
maxdepth=0x10) at bytecode.c:680
count = 0xd
op = 0x2
vectorp = 0x3988608
bytestr_length = 0xae
stack = {
pc = 0x33c6c06 "„†",
top = 0x82f1b8,
bottom = 0x82f1b0,
byte_string = 0x37e15b1,
byte_string_start = 0x33c6b90 "\b…",
constants = 0x3988605,
next = 0x82f4f0
}
top = 0x82f1b0
result = 0x0
#4 0x01023be1 in funcall_lambda (fun=0x39a4005, nargs=0x0,
arg_vector=0x82f3e8) at eval.c:3211
val = 0x6e44
syms_left = 0x2b36802
next = 0x2b8f582
count = 0xd
i = 0x0
optional = 0x0
rest = 0x0
#5 0x010236c0 in Ffuncall (nargs=0x1, args=0x82f3e4) at eval.c:3070
fun = 0x39a4005
original_fun = 0x399bc02
funcar = 0x395c3a6
numargs = 0x0
lisp_numargs = 0x101a6d7
val = 0x6e44
backtrace = {
next = 0x82f5b0,
function = 0x82f3e4,
args = 0x82f3e8,
nargs = 0x0,
evalargs = 0x0,
debug_on_exit = 0x0
}
internal_args = 0x82f3e8
i = 0x3c40ea3
#6 0x0116962f in Fbyte_code (bytestr=0x37f4ee1, vector=0x39aae05,
maxdepth=0x10) at bytecode.c:680
count = 0xd
op = 0x0
vectorp = 0x39aae08
bytestr_length = 0x73
stack = {
pc = 0x33c8060 "ˆ\016\030ƒi",
top = 0x82f3e4,
bottom = 0x82f3e0,
byte_string = 0x37f4ee1,
byte_string_start = 0x33c800c "Æ\b!ƒ\021",
constants = 0x39aae05,
next = 0x82f730
}
top = 0x82f3e4
result = 0x0
#7 0x01023be1 in funcall_lambda (fun=0x39a9885, nargs=0x1,
arg_vector=0x82f614) at eval.c:3211
val = 0x2b36802
syms_left = 0x2b36802
next = 0x399bf1a
count = 0xb
i = 0x1
optional = 0x1
rest = 0x0
#8 0x010236c0 in Ffuncall (nargs=0x2, args=0x82f610) at eval.c:3070
fun = 0x39a9885
original_fun = 0x399bf02
funcar = 0x2b6919b
numargs = 0x1
lisp_numargs = 0x101a6d7
val = 0x82f5f8
backtrace = {
next = 0x82f7f0,
function = 0x82f610,
args = 0x82f614,
nargs = 0x1,
evalargs = 0x0,
debug_on_exit = 0x0
}
internal_args = 0x2b36802
i = 0x3a8cc93
#9 0x0116962f in Fbyte_code (bytestr=0x37f8691, vector=0x39a3a05,
maxdepth=0x14) at bytecode.c:680
count = 0x8
op = 0x1
vectorp = 0x39a3a08
bytestr_length = 0xf8
stack = {
pc = 0x33c869a "ˆ\202ñ",
top = 0x82f614,
bottom = 0x82f610,
byte_string = 0x37f8691,
byte_string_start = 0x33c8628 "p\020Æ ˆÇ`È\"‰\031ƒ\022",
constants = 0x39a3a05,
next = 0x0
}
top = 0x82f610
result = 0x82f4f4
#10 0x01023be1 in funcall_lambda (fun=0x39a9265, nargs=0x1,
arg_vector=0x82f8a4) at eval.c:3211
val = 0x0
syms_left = 0x2b36802
next = 0x2b60c4a
count = 0x5
i = 0x1
optional = 0x1
rest = 0x0
#11 0x010236c0 in Ffuncall (nargs=0x2, args=0x82f8a0) at eval.c:3070
fun = 0x39a9265
original_fun = 0x3967f7a
funcar = 0x2b36802
numargs = 0x1
lisp_numargs = 0x1005b99
val = 0x82f838
backtrace = {
next = 0x82fab0,
function = 0x82f8a0,
args = 0x82f8a4,
nargs = 0x1,
evalargs = 0x0,
debug_on_exit = 0x0
}
internal_args = 0x82f808
i = 0x2b36802
#12 0x01168b17 in Fcall_interactively (function=0x3967f7a,
record_flag=0x2b36802, keys=0x2b3bb05)
at callint.c:869
val = 0x2cadb45
args = 0x82f8a0
visargs = 0x82f880
specs = 0x37fb191
filter_specs = 0x37fb191
teml = 0x11f25dd
up_event = 0x2b36802
enable = 0x2b36802
speccount = 0x3
next_event = 0x1
prefix_arg = 0x2b36802
string = 0x82f8c0 "P"
tem = 0x13a6b5c ""
varies = 0x82f860
i = 0x2
j = 0x1
count = 0x1
foo = 0x3a73dce
prompt1 = '\000' <repeats 99 times>
tem1 = 0x0
arg_from_tty = 0x0
gcpro1 = {
next = 0x2b41e42,
var = 0x2b36802,
nvars = 0x2b36802
}
gcpro2 = {
next = 0x2b41e42,
var = 0x2b41522,
nvars = 0x82f9b8
}
gcpro3 = {
next = 0x2bcb366,
var = 0x2b41522,
nvars = 0x2
}
gcpro4 = {
next = 0x2bcb37e,
var = 0x2b36802,
nvars = 0x2
}
gcpro5 = {
next = 0x4905268,
var = 0x2b36802,
nvars = 0x2b36802
}
key_count = 0x1
record_then_fail = 0x0
save_this_command = 0x3967f7a
save_last_command = 0x3967fda
save_this_original_command = 0x3967f7a
save_real_this_command = 0x3967f7a
#13 0x010234f7 in Ffuncall (nargs=0x4, args=0x82fb20) at eval.c:3030
fun = 0x139132d
original_fun = 0x2b5b5ca
funcar = 0x2b57b33
numargs = 0x3
lisp_numargs = 0x101ac15
val = 0x82fb18
backtrace = {
next = 0x0,
function = 0x82fb20,
args = 0x82fb24,
nargs = 0x3,
evalargs = 0x0,
debug_on_exit = 0x0
}
internal_args = 0x82fb24
i = 0x2b41a12
#14 0x0102308f in call3 (fn=0x2b5b5ca, arg1=0x3967f7a, arg2=0x2b36802,
arg3=0x2b36802)
at eval.c:2850
ret_ungc_val = 0x102422a
gcpro1 = {
next = 0x35fc086,
var = 0x2b36802,
nvars = 0x4
}
args = {0x2b5b5ca, 0x3967f7a, 0x2b36802, 0x2b36802}
#15 0x01014f36 in Fcommand_execute (cmd=0x3967f7a, record_flag=0x2b36802,
keys=0x2b36802,
special=0x2b36802) at keyboard.c:10507
final = 0x39a9265
tem = 0x2b36802
prefixarg = 0x2b36802
#16 0x0100787b in command_loop_1 () at keyboard.c:1904
scount = 0x2
cmd = 0x3967f7a
lose = 0x82fcd8
keybuf = {0x80, 0x144, 0x82fc98, 0x1197215, 0x1000, 0x1bc, 0x30a8,
0x2b54a00, 0x2, 0x0,
0x2, 0x2, 0x0, 0x2, 0x82fde0, 0x0, 0x0, 0x82fcb4, 0x82fb50, 0x0,
0x0, 0x0, 0x0, 0x0,
0x0, 0x0, 0x0, 0x0, 0x2b36802, 0x2c0a702}
i = 0x1
prev_modiff = 0x62
prev_buffer = 0x48b4000
already_adjusted = 0x0
#17 0x01020fc4 in internal_condition_case (bfun=0x10061fd <command_loop_1>,
handlers=0x2b444da,
hfun=0x1005bee <cmd_error>) at eval.c:1490
val = 0x31f77de
c = {
tag = 0x2b36802,
val = 0x2b36802,
next = 0x82fde0,
gcpro = 0x0,
jmp = {0x82fda8, 0x7ffde000, 0x65002e, 0x650078, 0x82fcdc,
0x1020f5c, 0x82ffe0, 0x0,
0x82fdd8, 0x3, 0x1, 0x82fde4, 0x77c30065, 0x0, 0x1, 0xa452f0},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0x0,
pdlcount = 0x2,
poll_suppress_count = 0x0,
interrupt_input_blocked = 0x0,
byte_stack = 0x0
}
h = {
handler = 0x2b444da,
var = 0x2b36802,
chosen_clause = 0x82fde4,
tag = 0x82fd20,
next = 0x0
}
#18 0x01005f62 in command_loop_2 () at keyboard.c:1360
val = 0x0
#19 0x01020ab5 in internal_catch (tag=0x2b441b2, func=0x1005f3f
<command_loop_2>, arg=0x2b36802)
at eval.c:1226
c = {
tag = 0x2b441b2,
val = 0x2b36802,
next = 0x0,
gcpro = 0x0,
jmp = {0x82fe58, 0x7ffde000, 0x65002e, 0x650078, 0x82fdcc,
0x1020aa6, 0x82ffe0, 0x0,
0x2b69aea, 0x2b691cb, 0x2b36802, 0x2b40000, 0x2f2a5f4, 0x2b36802,
0x82fe48,
0x2b691cb},
backlist = 0x0,
handlerlist = 0x0,
lisp_eval_depth = 0x0,
pdlcount = 0x2,
poll_suppress_count = 0x0,
interrupt_input_blocked = 0x0,
byte_stack = 0x0
}
#20 0x01005f18 in command_loop () at keyboard.c:1339
No locals.
#21 0x0100580a in recursive_edit_1 () at keyboard.c:954
count = 0x1
val = 0x82feb0
#22 0x0100596e in Frecursive_edit () at keyboard.c:1016
count = 0x0
buffer = 0x2b36802
#23 0x010027c6 in main (argc=0x1, argv=0xa42678) at emacs.c:1833
dummy = 0x7ffde000
stack_bottom_variable = 0x7f
do_initial_setlocale = 0x1
skip_args = 0x0
no_loadup = 0x0
junk = 0x0
dname_arg = 0x0
Lisp Backtrace:
"pos-visible-in-window-p" (0x82f1b4)
"gnus-summary-recenter" (0x82f3e8)
"gnus-summary-display-article" (0x82f614)
"gnus-summary-next-page" (0x82f8a4)
"call-interactively" (0x82fb24)
(gdb)
(gdb)
(gdb) frame
#0 0x01030355 in pos_visible_p (w=0x307c800, charpos=0x5ad, x=0x82f0c4,
y=0x82f0c0,
rtop=0x82f0d8, rbot=0x82f0d4, rowh=0x82f0d0, vpos=0x82f0cc) at xdisp.c:1396
1396 for (; glyph < end
(gdb) p rowh
$1 = (int *) 0x82f0d0
(gdb) prow
y=14 x=0 pwid=819 a+d=11+3=14 phys=11+3=14 vis=14 L=0 T=117 R=0
start=1 end=122 DISP TRUNC:R
(gdb) p w
$2 = (struct window *) 0x307c800
(gdb) pwin
Window 1 *Summary nntp+news.gmane.org:gmane.text.xml.schema.devel*
start=1 end:pos=0 vpos=3 vscroll=0
cursor: y=14 x=273 vpos=1 hpos=39 phys: y=14 x=273 vpos=1 hpos=39 ON blk=OFF
(gdb) p glyph
$3 = (struct glyph *) 0x38d0020
(gdb) pg
STRETCH[0+0] pos=0 w=5 a+d=0+0 face=47 vof=909 N/A OVL [ slice=24,909,0,0
(gdb)
--------------------------------------------------------------------------------
With charpos=0x5ad in the trace above, I ran gnus again and opened the summary
buffer for the same group. Doing 'M-x goto-char 1453' puts point on '...' in
the summary buffer, and 'M-x describe char' shows:
character: C-j (10, #o12, #xa)
preferred charset: ascii (ASCII (ISO646 IRV))
code point: 0x0A
syntax: which means: whitespace
buffer code: #x0A
file code: #x0A (encoded by coding system utf-8-dos)
display: by this font (glyph code)
uniscribe:-outline-DejaVu Sans
Mono-normal-normal-normal-mono-12-*-*-*-c-*-iso8859-1 (#x03)
Character code properties: customize what to show
name: <control>
old-name: LINE FEED (LF)
general-category: Cc (Other, Control)
There is an overlay here:
From 1453 to 1816
evaporate t
invisible gnus-sum
There are text properties here:
gnus-number 7068
--------------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: emacs-21.1.94 crash in gnus on Windows
2010-03-16 12:53 ` Andy Moreton
@ 2010-03-16 15:26 ` David Kastrup
2010-03-16 20:34 ` Andy Moreton
2010-03-16 19:47 ` Eli Zaretskii
1 sibling, 1 reply; 20+ messages in thread
From: David Kastrup @ 2010-03-16 15:26 UTC (permalink / raw)
To: emacs-devel
Andy Moreton <andrewjmoreton@googlemail.com> writes:
> On 16/03/2010 10:33, Eli Zaretskii wrote:
>>> From: Andy Moreton<andrewjmoreton@gmail.com>
>>> Date: Mon, 15 Mar 2010 23:40:27 +0000
>>>
>>> I've built 21.1.94 pretest on WinXP SP3 with MinGW gcc, and I'm seeing
>>> a repeatable crash in gnus. Running emacs under gdb I managed to capture
>>> a crash, with the following results:
If it is really 21.1.94, it is rather old. Can't you build a newer version?
--
David Kastrup
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: emacs-21.1.94 crash in gnus on Windows
2010-03-16 12:53 ` Andy Moreton
2010-03-16 15:26 ` David Kastrup
@ 2010-03-16 19:47 ` Eli Zaretskii
2010-03-16 20:42 ` Andy Moreton
1 sibling, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2010-03-16 19:47 UTC (permalink / raw)
To: Andy Moreton; +Cc: emacs-devel
> Date: Tue, 16 Mar 2010 12:53:51 +0000
> From: Andy Moreton <andrewjmoreton@googlemail.com>
> CC: emacs-devel@gnu.org
>
> > First, please file a bug report with this information.
>
> I've sent a bug report (from another machine after recreating the crash).
Didn't see it yet. So I'm responding here, for the time being.
> emacs was configured on both machines with "--no-opt". I've added details of
> the crash in the bug report below.
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x01030355 in pos_visible_p (w=0x307c800, charpos=0x5ad, x=0x82f0c4,
> y=0x82f0c0, rtop=0x82f0d8,
> rbot=0x82f0d4, rowh=0x82f0d0, vpos=0x82f0cc) at xdisp.c:1396
> 1396 for (; glyph < end
Hmm, that's a strange place to get hit by SIGSEGV. Can you try to see
what exactly caused the crash? When in doubt, I usually disassemble
the vicinity of the address where it crashed (0x01030355 in this
case), find the instruction that crashed, and then compare the
disassembly to the source to find which source line the failed
instruction came from. The GDB command "info line" might help in the
initial estimation of the source line to which the failed address
belongs.
Thanks.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: emacs-21.1.94 crash in gnus on Windows
2010-03-16 15:26 ` David Kastrup
@ 2010-03-16 20:34 ` Andy Moreton
0 siblings, 0 replies; 20+ messages in thread
From: Andy Moreton @ 2010-03-16 20:34 UTC (permalink / raw)
To: emacs-devel
On Tue 16 Mar 2010, David Kastrup wrote:
> Andy Moreton <andrewjmoreton@googlemail.com> writes:
>
>> On 16/03/2010 10:33, Eli Zaretskii wrote:
>>>> From: Andy Moreton<andrewjmoreton@gmail.com>
>>>> Date: Mon, 15 Mar 2010 23:40:27 +0000
>>>>
>>>> I've built 21.1.94 pretest on WinXP SP3 with MinGW gcc, and I'm seeing
>>>> a repeatable crash in gnus. Running emacs under gdb I managed to capture
>>>> a crash, with the following results:
>
> If it is really 21.1.94, it is rather old. Can't you build a newer version?
Typo - its 23.1.94.1 (the latest pretest tarball).
AndyM
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: emacs-21.1.94 crash in gnus on Windows
2010-03-16 19:47 ` Eli Zaretskii
@ 2010-03-16 20:42 ` Andy Moreton
2010-03-16 21:49 ` Eli Zaretskii
0 siblings, 1 reply; 20+ messages in thread
From: Andy Moreton @ 2010-03-16 20:42 UTC (permalink / raw)
To: emacs-devel
On Tue 16 Mar 2010, Eli Zaretskii wrote:
>> Date: Tue, 16 Mar 2010 12:53:51 +0000
>> From: Andy Moreton <andrewjmoreton@googlemail.com>
>> CC: emacs-devel@gnu.org
>>
>> > First, please file a bug report with this information.
>>
>> I've sent a bug report (from another machine after recreating the crash).
>
> Didn't see it yet. So I'm responding here, for the time being.
Details at http://debbugs.gnu.org/cgi/bugreport.cgi?bug=5730
>> emacs was configured on both machines with "--no-opt". I've added details of
>> the crash in the bug report below.
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> 0x01030355 in pos_visible_p (w=0x307c800, charpos=0x5ad, x=0x82f0c4,
>> y=0x82f0c0, rtop=0x82f0d8,
>> rbot=0x82f0d4, rowh=0x82f0d0, vpos=0x82f0cc) at xdisp.c:1396
>> 1396 for (; glyph < end
>
> Hmm, that's a strange place to get hit by SIGSEGV. Can you try to see
> what exactly caused the crash? When in doubt, I usually disassemble
> the vicinity of the address where it crashed (0x01030355 in this
> case), find the instruction that crashed, and then compare the
> disassembly to the source to find which source line the failed
> instruction came from. The GDB command "info line" might help in the
> initial estimation of the source line to which the failed address
> belongs.
I'll try to reproduce it and report back if I can shed any further
light. I haven't supplied any command line arguments when running under
gdb - do I need to use "-Q" to get something you can reproduce ?
AndyM
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: emacs-21.1.94 crash in gnus on Windows
2010-03-16 20:42 ` Andy Moreton
@ 2010-03-16 21:49 ` Eli Zaretskii
2010-03-20 12:19 ` Andreas Schwab
0 siblings, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2010-03-16 21:49 UTC (permalink / raw)
To: Andy Moreton; +Cc: emacs-devel
> From: Andy Moreton <andrewjmoreton@gmail.com>
> Date: Tue, 16 Mar 2010 20:42:02 +0000
>
> >> Program received signal SIGSEGV, Segmentation fault.
> >> 0x01030355 in pos_visible_p (w=0x307c800, charpos=0x5ad, x=0x82f0c4,
> >> y=0x82f0c0, rtop=0x82f0d8,
> >> rbot=0x82f0d4, rowh=0x82f0d0, vpos=0x82f0cc) at xdisp.c:1396
> >> 1396 for (; glyph < end
> >
> > Hmm, that's a strange place to get hit by SIGSEGV. Can you try to see
> > what exactly caused the crash? When in doubt, I usually disassemble
> > the vicinity of the address where it crashed (0x01030355 in this
> > case), find the instruction that crashed, and then compare the
> > disassembly to the source to find which source line the failed
> > instruction came from. The GDB command "info line" might help in the
> > initial estimation of the source line to which the failed address
> > belongs.
>
> I'll try to reproduce it and report back if I can shed any further
> light. I haven't supplied any command line arguments when running under
> gdb - do I need to use "-Q" to get something you can reproduce ?
I doubt that this will help: it's hard to use Gnus with absolutely no
customizations, especially on Windows.
For now, I'm trying to understand what object causes the crash, and
why. That might give more ideas.
Thanks.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: emacs-21.1.94 crash in gnus on Windows
2010-03-16 21:49 ` Eli Zaretskii
@ 2010-03-20 12:19 ` Andreas Schwab
2010-03-20 15:45 ` Andreas Schwab
0 siblings, 1 reply; 20+ messages in thread
From: Andreas Schwab @ 2010-03-20 12:19 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Andy Moreton, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> For now, I'm trying to understand what object causes the crash, and
> why. That might give more ideas.
I have seen exactly the same crash. It appears to be some issue with
GC, because glyph.object was overwritten with string data.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: emacs-21.1.94 crash in gnus on Windows
2010-03-20 12:19 ` Andreas Schwab
@ 2010-03-20 15:45 ` Andreas Schwab
2010-03-20 16:20 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 20+ messages in thread
From: Andreas Schwab @ 2010-03-20 15:45 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Andy Moreton, emacs-devel
I appears to happen when the last line in a buffer is made invisible
with an elipsis spec (like the gnus-sum spec). Apparently the
code is accessing an uninitialized glyph row.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: emacs-21.1.94 crash in gnus on Windows
2010-03-20 15:45 ` Andreas Schwab
@ 2010-03-20 16:20 ` Eli Zaretskii
2010-03-20 16:24 ` Andreas Schwab
2010-03-20 16:29 ` Eli Zaretskii
2 siblings, 0 replies; 20+ messages in thread
From: Eli Zaretskii @ 2010-03-20 16:20 UTC (permalink / raw)
To: Andreas Schwab; +Cc: andrewjmoreton, emacs-devel
> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Andy Moreton <andrewjmoreton@gmail.com>, emacs-devel@gnu.org
> Date: Sat, 20 Mar 2010 16:45:45 +0100
>
> I appears to happen when the last line in a buffer is made invisible
> with an elipsis spec (like the gnus-sum spec). Apparently the
> code is accessing an uninitialized glyph row.
So it does not appear to be related to GC?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: emacs-21.1.94 crash in gnus on Windows
2010-03-20 15:45 ` Andreas Schwab
2010-03-20 16:20 ` Eli Zaretskii
@ 2010-03-20 16:24 ` Andreas Schwab
2010-03-20 16:31 ` Eli Zaretskii
2010-03-24 21:34 ` Chong Yidong
2010-03-20 16:29 ` Eli Zaretskii
2 siblings, 2 replies; 20+ messages in thread
From: Andreas Schwab @ 2010-03-20 16:24 UTC (permalink / raw)
To: cyd; +Cc: Eli Zaretskii, Andy Moreton, emacs-devel
This is fundamentally broken. move_it_to never produces glyphs, so the
complete glyph row is uninitialized. This was first broken by this
change:
commit 9d73ed0ef33ba0502c03e546a09d175ab35fdc75
Author: Chong Yidong <cyd@stupidchicken.com>
Date: Sat Jan 26 01:00:44 2008 +0000
(pos_visible_p): Handle the case where charpos falls on
invisible text covered with an ellipsis.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: emacs-21.1.94 crash in gnus on Windows
2010-03-20 15:45 ` Andreas Schwab
2010-03-20 16:20 ` Eli Zaretskii
2010-03-20 16:24 ` Andreas Schwab
@ 2010-03-20 16:29 ` Eli Zaretskii
2010-03-20 16:46 ` Andreas Schwab
2 siblings, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2010-03-20 16:29 UTC (permalink / raw)
To: Andreas Schwab; +Cc: andrewjmoreton, emacs-devel
> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Andy Moreton <andrewjmoreton@gmail.com>, emacs-devel@gnu.org
> Date: Sat, 20 Mar 2010 16:45:45 +0100
>
> I appears to happen when the last line in a buffer is made invisible
> with an elipsis spec (like the gnus-sum spec).
Last line in a buffer or last line on display? Lines that are not
displayed should not be subject to any processing during redisplay.
> Apparently the code is accessing an uninitialized glyph row.
Do you mean that in the code below
if (TEXT_PROP_MEANS_INVISIBLE (prop) == 2)
{
struct glyph_row *row = it.glyph_row;
struct glyph *glyph = row->glyphs[TEXT_AREA];
struct glyph *end = glyph + row->used[TEXT_AREA];
int x = row->x;
for (; glyph < end
&& (!BUFFERP (glyph->object)
|| glyph->charpos < charpos);
glyph++)
x += glyph->pixel_width;
top_x = x;
}
it.glyph_row points to uninitialized memory? That would be very
strange, since start_display and move_it_to, called just above this,
already worked on that glyph row. Did I miss something?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: emacs-21.1.94 crash in gnus on Windows
2010-03-20 16:24 ` Andreas Schwab
@ 2010-03-20 16:31 ` Eli Zaretskii
2010-03-24 13:50 ` Andy Moreton
2010-03-24 21:34 ` Chong Yidong
1 sibling, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2010-03-20 16:31 UTC (permalink / raw)
To: Andreas Schwab; +Cc: cyd, andrewjmoreton, emacs-devel
> From: Andreas Schwab <schwab@linux-m68k.org>
> Cc: Andy Moreton <andrewjmoreton@gmail.com>, emacs-devel@gnu.org, Eli Zaretskii <eliz@gnu.org>
> Date: Sat, 20 Mar 2010 17:24:06 +0100
>
> This is fundamentally broken. move_it_to never produces glyphs, so the
> complete glyph row is uninitialized.
Right, thanks.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: emacs-21.1.94 crash in gnus on Windows
2010-03-20 16:29 ` Eli Zaretskii
@ 2010-03-20 16:46 ` Andreas Schwab
0 siblings, 0 replies; 20+ messages in thread
From: Andreas Schwab @ 2010-03-20 16:46 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: andrewjmoreton, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: Andy Moreton <andrewjmoreton@gmail.com>, emacs-devel@gnu.org
>> Date: Sat, 20 Mar 2010 16:45:45 +0100
>>
>> I appears to happen when the last line in a buffer is made invisible
>> with an elipsis spec (like the gnus-sum spec).
>
> Last line in a buffer or last line on display?
There is an invisible overlay over the last line spanning from the
previous newline until before the last newline.
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: emacs-21.1.94 crash in gnus on Windows
2010-03-20 16:31 ` Eli Zaretskii
@ 2010-03-24 13:50 ` Andy Moreton
0 siblings, 0 replies; 20+ messages in thread
From: Andy Moreton @ 2010-03-24 13:50 UTC (permalink / raw)
To: emacs-devel
On Sat 20 Mar 2010, Eli Zaretskii wrote:
>> From: Andreas Schwab <schwab@linux-m68k.org>
>> Cc: Andy Moreton <andrewjmoreton@gmail.com>, emacs-devel@gnu.org, Eli Zaretskii <eliz@gnu.org>
>> Date: Sat, 20 Mar 2010 17:24:06 +0100
>>
>> This is fundamentally broken. move_it_to never produces glyphs, so the
>> complete glyph row is uninitialized.
>
> Right, thanks.
After looking at more gdb traces, I also see the glpyh being overwritten
with string data, so Andreas is seeing the same problem.
Can we have a fix for this in the next pretest please ?
AndyM
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: emacs-21.1.94 crash in gnus on Windows
2010-03-20 16:24 ` Andreas Schwab
2010-03-20 16:31 ` Eli Zaretskii
@ 2010-03-24 21:34 ` Chong Yidong
2010-03-25 4:14 ` Eli Zaretskii
1 sibling, 1 reply; 20+ messages in thread
From: Chong Yidong @ 2010-03-24 21:34 UTC (permalink / raw)
To: Andreas Schwab; +Cc: Eli Zaretskii, Andy Moreton, emacs-devel
Andreas Schwab <schwab@linux-m68k.org> writes:
> This is fundamentally broken. move_it_to never produces glyphs, so the
> complete glyph row is uninitialized. This was first broken by this
> change:
>
> commit 9d73ed0ef33ba0502c03e546a09d175ab35fdc75
> Author: Chong Yidong <cyd@stupidchicken.com>
> Date: Sat Jan 26 01:00:44 2008 +0000
>
> (pos_visible_p): Handle the case where charpos falls on
> invisible text covered with an ellipsis.
Yes, this patch is wrong. Looking through the archives, it seems to
have been meant to address the problem at
http://lists.gnu.org/archive/html/emacs-devel/2008-01/msg00945.html
However, looking at that recipe, it seems the problem is actually
handled by my 2009-01-10 (it_method == GET_FROM_DISPLAY_VECTOR) change
instead. So either my 2008-01-26 change was bogus all along, or some
other change in the meantime made it bogus.
I've reverted it in the branch; thanks for investigating.
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: emacs-21.1.94 crash in gnus on Windows
2010-03-24 21:34 ` Chong Yidong
@ 2010-03-25 4:14 ` Eli Zaretskii
2010-03-25 16:35 ` Chong Yidong
0 siblings, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2010-03-25 4:14 UTC (permalink / raw)
To: Chong Yidong; +Cc: andrewjmoreton, schwab, emacs-devel
> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: Andy Moreton <andrewjmoreton@gmail.com>, emacs-devel@gnu.org,
> Eli Zaretskii <eliz@gnu.org>
> Date: Wed, 24 Mar 2010 17:34:14 -0400
>
> However, looking at that recipe, it seems the problem is actually
> handled by my 2009-01-10 (it_method == GET_FROM_DISPLAY_VECTOR) change
> instead. So either my 2008-01-26 change was bogus all along, or some
> other change in the meantime made it bogus.
>
> I've reverted it in the branch; thanks for investigating.
But the part that you left in the code also uses it.glyph_row, which
is garbage after a call to move_it_to. There's a single use of
it.glyph_row->x before the call to PRODUCE_GLYPHS (&it2), and I think
that needs to be fixed as well, because it potentially dereferences a
bad pointer.
Or did I miss something?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: emacs-21.1.94 crash in gnus on Windows
2010-03-25 4:14 ` Eli Zaretskii
@ 2010-03-25 16:35 ` Chong Yidong
2010-03-25 19:51 ` Eli Zaretskii
0 siblings, 1 reply; 20+ messages in thread
From: Chong Yidong @ 2010-03-25 16:35 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: andrewjmoreton, schwab, emacs-devel
Eli Zaretskii <eliz@gnu.org> writes:
> But the part that you left in the code also uses it.glyph_row, which
> is garbage after a call to move_it_to. There's a single use of
> it.glyph_row->x before the call to PRODUCE_GLYPHS (&it2), and I think
> that needs to be fixed as well, because it potentially dereferences a
> bad pointer.
>
> Or did I miss something?
I don't see the failure condition. This branch handles the special case
of charpos == 1 or charpos above the top of the window. Since
start_display initialized the iterator using the desired matrix of the
window, it.glyph_row should always be valid.
Or am I confused?
^ permalink raw reply [flat|nested] 20+ messages in thread
* Re: emacs-21.1.94 crash in gnus on Windows
2010-03-25 16:35 ` Chong Yidong
@ 2010-03-25 19:51 ` Eli Zaretskii
0 siblings, 0 replies; 20+ messages in thread
From: Eli Zaretskii @ 2010-03-25 19:51 UTC (permalink / raw)
To: Chong Yidong; +Cc: andrewjmoreton, schwab, emacs-devel
> From: Chong Yidong <cyd@stupidchicken.com>
> Cc: schwab@linux-m68k.org, andrewjmoreton@gmail.com, emacs-devel@gnu.org
> Date: Thu, 25 Mar 2010 12:35:05 -0400
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > But the part that you left in the code also uses it.glyph_row, which
> > is garbage after a call to move_it_to. There's a single use of
> > it.glyph_row->x before the call to PRODUCE_GLYPHS (&it2), and I think
> > that needs to be fixed as well, because it potentially dereferences a
> > bad pointer.
> >
> > Or did I miss something?
>
> I don't see the failure condition. This branch handles the special case
> of charpos == 1 or charpos above the top of the window. Since
> start_display initialized the iterator using the desired matrix of the
> window, it.glyph_row should always be valid.
>
> Or am I confused?
it.glyph_row is indeed initialized in start_display. But are you sure
it.glyph_row->x is set correctly? move_it_to does not produce glyphs
in glyph_row, so who computes glyph_row->x ?
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2010-03-25 19:51 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-03-15 23:40 emacs-21.1.94 crash in gnus on Windows Andy Moreton
2010-03-16 10:33 ` Eli Zaretskii
2010-03-16 12:53 ` Andy Moreton
2010-03-16 15:26 ` David Kastrup
2010-03-16 20:34 ` Andy Moreton
2010-03-16 19:47 ` Eli Zaretskii
2010-03-16 20:42 ` Andy Moreton
2010-03-16 21:49 ` Eli Zaretskii
2010-03-20 12:19 ` Andreas Schwab
2010-03-20 15:45 ` Andreas Schwab
2010-03-20 16:20 ` Eli Zaretskii
2010-03-20 16:24 ` Andreas Schwab
2010-03-20 16:31 ` Eli Zaretskii
2010-03-24 13:50 ` Andy Moreton
2010-03-24 21:34 ` Chong Yidong
2010-03-25 4:14 ` Eli Zaretskii
2010-03-25 16:35 ` Chong Yidong
2010-03-25 19:51 ` Eli Zaretskii
2010-03-20 16:29 ` Eli Zaretskii
2010-03-20 16:46 ` Andreas Schwab
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.