Vladimir Volovich writes:
> Hello,
>
> With xindy linux binary distributed in
> xindy-2.0d2-i386-linux-glibc2.tar.gz
>
> i get a segmentation fault while processing a simple 4-line raw index
> with a simple style file. Attached are two files in a tarball:
> test.raw and test.xdy. Here is a transcript:
>
> $ xindy -o test.ind test.xdy test.raw
> This is `xindy' version 2.0 (i386-linux-glibc2 binary version 2.0).
>
> Reading indexstyle...
> Loading module "test.xdy"...
> Loading module "misc/texindex.xdy"...
> Finished loading module "misc/texindex.xdy".
> Finished loading module "test.xdy".
> Finished reading indexstyle.
> Finalizing indexstyle... (done)
>
> Reading raw-index "test.raw"...
> *** - handle_fault error2 ! address = 0x7D234B not in [0x20195000,0x2028C6B8) !
> SIGSEGV cannot be cured. Fault address = 0x7D234B.
> Segmentation fault
> $
I assume that you use the older version of the xindy port for Linux.
This bug is known since July 1999 and has been reported on this
mailing list:
==================================================
Thomas Henlich writes:
> Processing the following files with xindy leads to a SEGMENTATION FAULT.
> Both i386-linux-glibc and i386-linux-elf versions are affected.
> The output is:
> =====
> ~/xindy$ xindy -L 3 -l test.xlg test.xdy test.raw
> This is `xindy' version 2.0 (i386-linux-glibc2 binary version 2.0).
>
> Opening logfile "test.xlg" (done)
> Reading indexstyle...
> Loading module "test.xdy"...
> Finished loading module "test.xdy".
> Finished reading indexstyle.
> Finalizing indexstyle... (done)
>
> Reading raw-index "test.raw"...
> Finished reading raw-index.
>
> Processing index...
> *** - handle_fault error2 ! address = 0x7D241E not in
> [0x20195000,0x2028C6C8) !
> SIGSEGV cannot be cured. Fault address = 0x7D241E.
> Speicherzugriffsfehler
>
> [...]
>
> Any clues? How can I debug xindy?
> --
> Thomas Henlich
The bug is caused by some rudimentary limitation on the length of
strings to be processed. There was a buffer of length 128 on the heap
which was not bounds-checked. I lifted the limit to 4096 for the
moment which should be enough for most applications.
The quick fix is to
#define STRING_MAX 1024
in "mkind.h" instead of 128 ;-)
If anybody seems to need more space for the length of keywords in his
applications, tell me. I'll integrate it into a future release...
==================================================
Please check out whether this solves your problem.
Cheers, Roger
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Roger Kehr email: kehr@informatik.tu-darmstadt.de
Department of Computer Science phone: +49 6151 16-6233
Darmstadt University of Technology fax: +49 6151 16-6229