> Date: Thu, 15 Jan 2026 21:27:51 +0100 > From: [email protected] > > On Thu, Jan 15, 2026 at 05:12:39PM +0000, Gavin Smith wrote: > > On Thu, Jan 15, 2026 at 03:48:19PM +0200, Eli Zaretskii wrote: > > > The second failure is strange: there's no *.diff files, but 2 of the 3 > > > files in res_parser are very different from out_parser. The file > > > out_parser/formatting.tex is empty, and out_parser/formatting.2 is > > > missing 21 lines, and has this extra line: > > > > > > +Free to wrong pool 13beec0 not 88040400 at > > > ../perl/Texinfo/Convert/LaTeX.pm line 2674. > > > > > > This looks like some code used 'free' from a long 'malloc' to free > > > some memory, like the allocation was done by Perl, but 'free' is from > > > tta/C code, or vice versa. How to investigate this? > > > > Yes, you are probably right about the wrong 'free' being used. > > > > The function called at that line in LaTeX.pm is index_element_sort_string > > in tta/C/main/manipulate_indices.c. But I don't know which "free" call > > would be responsible under that function or why the Perl malloc would > > have been used. > > I did not find either by looking at that code, but I did an extensive > search of malloc/realloc/free/strdup... in the code compiled with the > Perl headers and found quite a bit of missing use of non_perl_* > functions. One of those was for subentries, could be the culprit here. > > I just committed the change.
Thanks, I've applied to the 7.2.90 tree the changes in commit 5ddc6700767979da202ecb0a6411fb9c3b4e17f8, and the coverage_formatting_latex test now passes (and no new failures happen). > > > And how do I know whether the tta/ tests were run with or without the > > > XS extensions and the rest of C code in the tta/ directory? (It might > > > be a good idea to announce this when the test suite starts.) > > > > > > All the other tests either succeeded or were skipped. > > > > I think it's likely the XS modules were used in your test run. I think > > it's a good idea to report at the start of the output whether XS modules > > are enabled. > > If we do that (it is not clear to me where to do that, as the tests are > independent), I think that it would be better to be more specific than > XS/non XS, but rather show up to which step is XS used, by using the > information in the TEXINFO_XS_* environment variables, and also the > information in TEXINFO_XS_EXTERNAL_*. Also, if that kind of information > is output for tests of texi2any, it could be a good thing to add the > information on whether the Perl texi2any or the C texi2any > implementation is used. Yes, please. Given the large number of extensions and replacements, it would be good to know what is actually being tested. Especially if one wants to test both with and without the extensions, by manipulating the various TEXINFO_XS_* and TEXINFO_XS_EXTERNAL_* variables.
