Subject: Re: bug#7876: Crash: infinite recursion in next_element_from_buffer

From: Eli Zaretskii <[email-masked]>
Date: Thu, 20 Jan 2011 18:50:34 -0500

> From: Stefan Monnier <[email-masked]>
> Date: Thu, 20 Jan 2011 14:49:31 -0500
> Cc: 
> 
>   #8  0x080a8ea8 in next_element_from_buffer (it=0xbfffbd40) at xdisp.c:6655
>   #9  0x080a8ebd in next_element_from_buffer (it=0xbfffbd40) at xdisp.c:6656
>   #10 0x080a8ebd in next_element_from_buffer (it=0xbfffbd40) at xdisp.c:6656
>   [...]
> 
> where 6656 is the second line of:
> 
> 	  handle_stop (it);
> 	  return GET_NEXT_DISPLAY_ELEMENT (it);

Looks like handle_stop is not updating it->stop_charpos, for some
reason.  Could you verify that this is the case?  The GDB command
"pit" will display the important fields of the iterator object,
including stop_charpos.

If this is true, please trace through handle_stop, and see why this
happens.  It has this code near the end:

  /* Determine where to stop next.  */
  if (handled == HANDLED_NORMALLY)
    compute_stop_pos (it);

If compute_stop_pos is never called, it could explain the infinite
recursion, but then we will have to find out why `handled' never gets
set to HANDLED_NORMALLY.

I will be unable to try debugging this myself, at least for the next
few days.  But I can explain the logic behind the
next_element_from_buffer & handle_stop dance, if you don't know that
already.  The idea is quite simple.  Let me know if you need this.

HTH