Re: Fix for #63426 - GtkTextView core dumps on deletion

[dov imagic weizmann ac il]

This is a duplicate of my bug 63326. The code seems to crash because
of a recursion problem. The trace looks as follows:

#0  0x4019be90 in ensure_end_iter_line (tree=0x8065718) at gtktextbtree.c:3198
#1  0x4019c008 in _gtk_text_line_contains_end_iter (line=0x80656b8, 
    tree=0x8065718) at gtktextbtree.c:3252
#2  0x401aa879 in forward_line_leaving_caches_unmodified (real=0xbf8000a0)
    at gtktextiter.c:1780
#3  0x401ab8d3 in gtk_text_iter_forward_line (iter=0xbf8000a0)
    at gtktextiter.c:2499
#4  0x401acd67 in find_paragraph_delimiter_for_line (iter=0xbfffe4d0)
    at gtktextiter.c:3769
#5  0x401ace07 in gtk_text_iter_forward_to_line_end (iter=0xbfffe4d0)
    at gtktextiter.c:3804
#6  0x401abfc1 in find_by_log_attrs (iter=0xbfffe4d0, 
    func=0x401ac4f4 <find_backward_cursor_pos_func>, forward=0, 
    already_moved_initially=1) at gtktextiter.c:2949
#7  0x401abfd3 in find_by_log_attrs (iter=0xbfffe4d0, 
    func=0x401ac4f4 <find_backward_cursor_pos_func>, forward=0, 
    already_moved_initially=1) at gtktextiter.c:2952

and the last call is repeated several thousand times. Indeed
the problem is with  gtk_text_iter_forward_to_line_end ().
In the following example the buffer contains the following:

    a\n
    _

and _ is the position of the cursor. Pressing <BackSpace> and
putting a break point in find_by_log_attrs() [gtktextiter.c:2914], we have 
the following iter value at entry:

    (line, line_offs) = 1, 0

Sicne we are going backwards (forward = 0) the line is decreased
by the call to gtk_text_iter_backward_line(iter) [2946] whereupon

    (line, line_offs) = 0, 0

Since gtk_text_iter_ends_line (iter) [line 2948] returns false,
we call gtk_text_iter_forward_to_line_end (iter) to put the iter
at the end of the line. And here is the bug, because after this
call:

    (line, line_offs) = 1, 0

And not the expected (0,1) . 

Looking inside gtk_text_iter_forward_to_line_end () the call to
  
   new_offset = find_paragraph_delimiter_for_line (iter);

new_offset becomes 0. But it shouldn't it be 1 since there is one
character on line 0 in the buffer? This is as far as I got, and
thus it doesn't seem like the patch below is doing the right
thing, as it assumes that new_offset becomes 0. But perhaps it
should be. The documentation to find_paragraph_delimeter_for_line
doesn't say what it is supposed to return...

Dov



On Sun, Nov 04, 2001 at 12:36:53PM -0500, Havoc Pennington wrote:
> 
> Hans Breuer <hans breuer org> writes: 
> > --- from-cvs/gtk+/gtk/gtktextiter.c	Sat Oct 27 02:18:26 2001
> > +++ my-gtk/gtk+/gtk/gtktextiter.c	Sun Nov 04 17:34:24 2001
> > @@ -3802,8 +3802,14 @@
> >  
> >    current_offset = gtk_text_iter_get_line_offset (iter);
> >    new_offset = find_paragraph_delimiter_for_line (iter);
> > -  
> > -  if (current_offset < new_offset)
> > +
> > +  if (0 == new_offset) 
> > +    {
> > +      while (!gtk_text_iter_ends_line (iter))
> > +        gtk_text_iter_forward_char (iter);
> > +      return FALSE;
> > +    }
> > +  else if (current_offset < new_offset)
> >      {
> >        /* Move to end of this line. */
> >        gtk_text_iter_set_line_offset (iter, new_offset);
> > 
> 
> I don't understand this change; if new_offset == 0 and current_offset
> >= 0, then we should be moving to the end of the next line, because
> current_offset is already at or beyond the end of the current line.
> That's how the function docs read to me anyhow.
> 
> Also, this change should definitely not cause a segfault to appear or
> disappear; if this affects a segfault, then the segfault bug still
> exists and hasn't been fixed. If you can reproduce the segfault, can
> you add a backtrace to the bug report?
> 
> Havoc 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list