[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15365: 24.3.50; Segfault when calling vc-git-log-edit-toggle-amend

From: Eli Zaretskii
Subject: bug#15365: 24.3.50; Segfault when calling vc-git-log-edit-toggle-amend
Date: Sat, 14 Sep 2013 13:16:12 +0300

> Date: Sat, 14 Sep 2013 11:47:39 +0200
> From: martin rudalics <address@hidden>
> CC: address@hidden, address@hidden
>  >> So where was Dmitry's cursor?
>  >
>  > At PT, whose value was 78.
> So PT was not in the window and the fact that it apparently passed the
> earlier check (PT < CHARPOS (start)) means that PT was after the end of
> the window.  Is that conclusion correct?

No.  It was in the 3rd line:

  0: edges=(1,77),enb=0,r2l=0,cont=0,trunc=(0,0),at_zv=0
  1: edges=(77,78),enb=0,r2l=0,cont=0,trunc=(0,0),at_zv=0
  2: edges=(78,79),enb=0,r2l=0,cont=0,trunc=(0,0),at_zv=0

As you see, the 3rd line begins with character position 78, and that's
where point is.  So the cursor should be displayed there.

>  > But I probably don't understand what you wanted to ask or tell.
> Figure out why row_containing_pos (w, PT, r0, NULL, 0) returned 0.

That's easy: r0->enabled_p is zero (that's what enb=0 is about).  And
row_containing_pos immediately returns NULL in that case.

> And why try_window_id was supposed to abort in this case and why
> this abort didn't occur more frequently.

My analysis concluded that it wasn't supposed to abort, just not call
set_cursor_from_row in that case.  The call to abort was added long
ago, when row_containing_pos got a minor modification, and the person
who made the change thought that perhaps that change will cause
damage.  I think we can remove that call to abort now.  And if that
causes any regressions, there's a more drastic way of calling GIVE_UP
in that case.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]