bug#81568: 32.0.50; crash in Fnext_single_property_change

> From: [email protected]
> Cc: [email protected]
> Date: Sat, 08 Aug 2026 15:32:30 +0300
> 
> > Please try to figure out which data caused the segfault.  The code
> > where it happens is
> >
> >   next = next_interval (i);
> >   while (next
> > 	 && EQ (here_val, textget (next->plist, prop))
> > 	 && (NILP (limit) || next->position < XFIXNUM (limit)))
> >     next = next_interval (next);
> >
> > and according to the backtrace, the value of 'next' looks okay at
> > first sight.
> 
> We have a cycle, that is
> 
>    next == i

On what source line does this happen in the above snippet?

And how can a cycle cause a segfault?  It could cause an infloop, but
that's not what you see.

>    (gdb) p i
>    $14 = (INTERVAL) 0x55557a555b40
>    (gdb) p next
>    $15 = (INTERVAL) 0x55557a555b40
> 
> Note `next= ...` initialization
>    (gdb) p next_interval (i)
>    $16 = (struct interval *) 0x55557a555b08
> 
> is not of `i` pointer.

What do you mean by "is not of `i` pointer"?

INTERVAL is the same as 'struct interval *', because of this:

  typedef struct interval *INTERVAL;

> Having gdb session I tried to reproduce the cycle, only to interrupt that in few
> seconds when the loop count reached some large value
> 
>    (gdb) set $next=$16
>    (gdb) while i != $next
>    >set $next=next_interval ($next)
>    >set $cnt=$cnt+1
>    >end
>    ^CQuit
>    (gdb) p $cnt
>    $18 = 46189

Why does it matter?

I'm still confused regarding which part of the code above segfaults,
and what is the problematic data which causes that.

Thanks.