* 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 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 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 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 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: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
* 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: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
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.