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