#63 htsearch coredumps on FreeBSD

cannot reproduce
htsearch (60)

This is a strange and very bizarre occurence. On one of
our production webservers we have 3 copies of HTDig
3.1.5 running that have been going fine for a year or
more. When we needed to install another one we followed
the exact same procedures and it compiled and installed
fine. Running rundig completes succesfully, at least as
far as I can tell from running it with -vvv.
Unfortunately whenever htsearch is called it coredumps.

Here's the dump from gdb:

This GDB was configured as "i386-unknown-freebsd"...b
Core was generated by `htsearch'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libz.so.2...done.
Reading symbols from /usr/lib/libstdc++.so.3...done.
Reading symbols from /usr/lib/libm.so.2...done.
Reading symbols from /usr/lib/libc.so.4...done.
Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0 0x280f60fc in ostream::operator<< () from
(gdb) bt
#0 0x280f60fc in ostream::operator<< () from
#1 0x8056e68 in doFuzzy (ww=0x80b7580,
algorithms=@0xbfbfe248) at htsearch.cc:559
#2 0x80569a5 in setupWords (allWords=0x80b6530 "caep",
searchWords=@0xbfbffb24, boolean=0,
originalPattern=@0xbfbff28c) at htsearch.cc:522
#3 0x8054dd3 in main (ac=2, av=0xbfbffb90) at
#4 0x8049e95 in _start ()

I assumed the problem was that some library that it
linked against (probably libstdc++.so.3) had been
upgraded since we last built one but i'm not so sure
I took a spare machine, upgraded it to the latest
FreeBSD 4.3-STABLE and tried installing it and I Get
the exact same results. It compiles and installs fine,
rundig goes off without a hitch, but htsearch core
dumps in the exact same manner.

I've searched through all the archives and googled
around the web but i can find no reference to anything
similar, beyond the BSDI suggestions in the FAQ
(which, for the record, i've tried without success).


  • Geoff Hutchison

    Geoff Hutchison - 2002-02-12

    Logged In: YES

    I haven't heard of anyone being able to reproduce this bug on any platform. Certainly it would help to know where in htsearch.cc::doFuzzy the crash happens as this line number corresponds directly to calling doFuzzy, but not any of the doFuzzy code.

    Can you still reproduce this? If so, could you compile with optimization turned off and debugging turned on, don't strip the binaries and get a similar backtrace from gdb?


  • Geoff Hutchison

    Geoff Hutchison - 2002-02-12
    • milestone: --> cannot reproduce
    • status: open --> closed-out-of-date

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks