> From: Gavin Smith <gavinsmith0...@gmail.com>
> Date: Sun, 8 Oct 2023 08:50:51 +0100
> Cc: bug-texinfo@gnu.org
>
> The program appears to crash after the "@include version-stnd.texi" line
> which read a new input file. This suggests that the problem may be to
> do with reading input, somewhere in 'next_text' in input.c.
>
> I suggest commenting out the "@include" line:
>
> diff --git a/doc/info-stnd.texi b/doc/info-stnd.texi
> index 36d884a76a..883408ffcd 100644
> --- a/doc/info-stnd.texi
> +++ b/doc/info-stnd.texi
> @@ -4,7 +4,7 @@
> @c file is made first, and texi2dvi must include . first in the path.
> @comment %**start of header
> @setfilename info-stnd.info
> -@include version-stnd.texi
> +@c @include version-stnd.texi
> @settitle Stand-alone GNU Info @value{VERSION}
> @syncodeindex vr cp
> @syncodeindex fn cp
>
> and trying the command again. If it gets further, that would confirm
> there was a problem with included files.
Yes, it gets much further, I think to the very end? It still crashes,
though, after printing this:
GET_A_NEW_LINE
NEW LINE @bye
BEGIN LINE
COMMAND @bye
ABORT EMPTY in @appendix[A1][C4](p:1): empty_line; add || to ||
FINISHED_TOTALLY
GATHER AFTER BYE
> gdb /d/usr/Perl/bin/perl
>
> Then at the gdb prompt, run
>
> r ../tp/texi2any.pl info-stnd.texi
>
> Hopefully it shows you where the crash occurs.
I have some info, see below.
> If the "parsetexi" module was compiled with debugging information, I have
> always found on GNU/Linux that it is possible to debug the module just as
> you would debug a standalone program.
Alas, the default is not to compile parsetexi with debug info, at
least not a sufficient one (or maybe producing the shared library
doesn't keep the symbols). Here's what I get from GDB's "bt" command
from the crash site:
Starting program: d:\usr\Perl\bin\perl.exe ../tp/texi2any.pl info-stnd.texi
Program received signal SIGSEGV, Segmentation fault.
0x692a6fc6 in getdelim ()
from D:\gnu\texinfo-7.0.93\tp\Texinfo\XS\.libs\Parsetexi.dll
(gdb) bt
#0 0x692a6fc6 in getdelim ()
from D:\gnu\texinfo-7.0.93\tp\Texinfo\XS\.libs\Parsetexi.dll
#1 0x6928c993 in next_text ()
from D:\gnu\texinfo-7.0.93\tp\Texinfo\XS\.libs\Parsetexi.dll
#2 0x6928ba6a in parse_texi ()
from D:\gnu\texinfo-7.0.93\tp\Texinfo\XS\.libs\Parsetexi.dll
#3 0x6928bc58 in parse_texi_document ()
from D:\gnu\texinfo-7.0.93\tp\Texinfo\XS\.libs\Parsetexi.dll
#4 0x692840d0 in parse_file ()
from D:\gnu\texinfo-7.0.93\tp\Texinfo\XS\.libs\Parsetexi.dll
#5 0x6928219c in XS_Texinfo__Parser_parse_file ()
from D:\gnu\texinfo-7.0.93\tp\Texinfo\XS\.libs\Parsetexi.dll
#6 0x66c8b8bb in perl520!Perl_find_runcv () from d:\usr\Perl\bin\perl520.dll
Source code information is not available in the debug info, but from
looking at the disassembly of the code, I see that getdelim (from
Gnulib) calls realloc, which resolves to the default realloc
implementation of the MinGW libc. Isn't that dangerous, given that at
least some code in the extensions uses the Perl's malloc/free
implementation?
If the above information is not enough, I will try to build the
extensions with more extensive debug info, and see what GDB will tell
then. Alternatively, maybe you have ideas to try some code changes
based on the above.
Thanks.
