According to Shakaib Sayyid:
> I am getting a core dump on htsearch 3.1.5 using linux 6.2--2.2.14-5.0kernel.
> following is the output from "gdb htsearch core":
>
> Core was generated by `htsearch'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/lib/libz.so.1...done.
> Reading symbols from /usr/lib/libstdc++-libc6.1-1.so.2...done.
> Reading symbols from /lib/libm.so.6...done.
> Reading symbols from /lib/libc.so.6...done.
> Reading symbols from /lib/ld-linux.so.2...done.
> #0 0x807f05a in __bam_cmp () at HtCodec.cc:20
> 20 // End of HtCodec.cc
> (gdb) bt
> #0 0x807f05a in __bam_cmp () at HtCodec.cc:20
> #1 0x8085c27 in __bam_search () at HtCodec.cc:20
> #2 0x8081255 in __bam_c_search () at HtCodec.cc:20
> #3 0x807fa6f in __bam_c_get () at HtCodec.cc:20
> #4 0x8067217 in __db_get () at HtCodec.cc:20
> #5 0x805ab66 in DB2_db::Get (this=0x80d85f0, key=@0xbfffe250, data=@0xbfffe2b0)
> at DB2_db.cc:334
> #6 0x8059ddb in Database::Get (this=0x80d85f0, key=0x80ec2a0 "peter",
> data=@0xbfffe2b0) at Database.cc:77
Looks like a database corruption problem. Try rebuilding the database
from scratch, e.g. using "rundig", and see if that gets rid of the
problem. If the problem recurs after this, it could indicate something
else is going wrong. Note too that there is no lockout on the database,
so if you accidentally start two processes (htdig and/or htmerge) that
try to update the database simultaneously, that can really mess up
the database.
--
Gilles R. Detillieux E-mail: <[EMAIL PROTECTED]>
Spinal Cord Research Centre WWW: http://www.scrc.umanitoba.ca/~grdetil
Dept. Physiology, U. of Manitoba Phone: (204)789-3766
Winnipeg, MB R3E 3J7 (Canada) Fax: (204)789-3930
------------------------------------
To unsubscribe from the htdig mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
List archives: <http://www.htdig.org/mail/menu.html>
FAQ: <http://www.htdig.org/FAQ.html>
