all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* 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.