Front page | perl.perl5.porters |
Postings from November 2022
Hi Dave, On Sun, 13 Nov 2022, Dave Mitchell wrote: > On Sun, Nov 13, 2022 at 02:22:28AM +0100, Uwe Düffert wrote: >> Well, TROUBLE IS BACK! >> >> While with perl-5.37.4 it was still possible to build texinfo-7.0, that >> fails with perl-5.37.5 - in a very similar way as in July: >> >> The perl command from texinfo-7.0 doc build as in >> https://uwe-dueffert.de/code/perl5.37.5/texinfo-7.0_doc_problem.sh >> has memory access issues again: >> https://uwe-dueffert.de/code/perl5.37.5/texinfo-7.0_valgrind.log > > It's very unclear what problem you are describing. Sorry to you too for not being more verbose. The whole thread can be found at https://www.nntp.perl.org/group/perl.perl5.porters/2022/07/msg264269.html > Are saying > 1) that texinfo-7.0 won't install with a normal perl-5.37.5 build? Basically: Yes. texinfo-7.0 does not *build* if perl-5.37.5 is installed, whereas it does if perl-5.37.3 or perl-5.37.4 is installed. At least for me, but perfectly reproducible. > In which case what is the error? A single perl command from texinfo build, namely /bin/perl tp/texi2any -I . -o texinfo.info texinfo.texi bails out with "malloc_consolidate(): unaligned fastbin chunk detected" > Is the valgrind log just provided as > something that might help us identify the problem? Exactly. Maybe above malloc_consolidate() message already helps you more nowadays - the output from perl-5.37.1 and perl-5.37.2 in July was way more cryptic (something about invalid locale). In both cases the cause was invalid memory access within perl, which is what valgrind shows. > Note that building a perl with debugging symbols means the valgrind > output displays line numbers as well as function names, which makes > understanding the output easier. What kind of debugging symbols are you interested in? Last time, one suggestion was to build perl with -DDEBBUGGING, but that completely concealed the problem, i.e. it produced lots of usually helpful output, but also made texinfo build run through successfully, i.e. the problem did not occur, i.e. bad memory access only modifed something noncritical then such as the additional debug code. So does it (expectedly) help if I compile perl with any certain Configure switch? And/or run it with any certain environment variable set? Or shall I try to provide a stripped down test case instead of saying "whole texinfo-7.0 build"? Regards UweThread Previous | Thread Next