[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#7876: Crash: infinite recursion in next_element_from_buffer
From: |
Eli Zaretskii |
Subject: |
bug#7876: Crash: infinite recursion in next_element_from_buffer |
Date: |
Thu, 20 Jan 2011 18:50:34 -0500 |
> From: Stefan Monnier <monnier@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