On Thu, Jun 05, 2025 at 05:03:38PM +0100, Gavin Smith wrote:
> FAIL: t/converters_tests.t 1527 -
> indices_in_begin_tables_lists_entries_after_item tree
This started to fail after
commit 359b73825d2b68f3fd76d07a54c231d77464a3df
Store Texinfo tree element SV in C
I realized that in the new code only the SV refcount was increased, not
the associated HV, I just fixed that. But it does not solve the issue.
I investigated indices_in_begin_tables_lists_entries_after_item failure
and found what is the visible issue, but I can't find where it comes from.
The issue is that an inteize second content (before_item) is replaced by the
third (an @item) when an index entry that is in the before_item is
reparented to the @item.
The code is in the move_index_entries_after_items sub in
Texinfo/ManipulateTree.pm. In the following loop, where the
$previous_ending_container->{'contents'}->[$i] element is reparented to
$item_container, $previous_ending_container is replaced by $item_container
in the itemize $current contents elements list.
for (my $i = $last_entry_idx; $i < $contents_nr; $i++) {
$previous_ending_container->{'contents'}->[$i]->{'parent'}
= $item_container;
}
I checked the refcount, and even before the change there did not seem to
be anything problematic (there could have been, though, if all the
references were destroyed in Perl, although this is not very likely).
A possibility could be that the itemize content points to the parent of
the index entry instead of pointing directly to the element, but both
the code and some printout of elements references did not show anything
that could be consistent with that possiblility.
I do not have any good idea on what more could be done to understand
what is going on.
--
Pat
