GNU bug report logs - #7876
Crash: infinite recursion in next_element_from_buffer

Previous Next

Full log

View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 7876 <at> debbugs.gnu.org
Subject: bug#7876: Crash: infinite recursion in next_element_from_buffer
Date: Thu, 20 Jan 2011 18:50:34 -0500

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.