According to Joe R. Jah:
> On Mon, 11 Jun 2001, Gilles Detillieux wrote:
> > Subject: Re: [htdig-dev] troubles!
> >
> > Try the latest snapshot from June 10. It should fix this problem
> > (among others).
>
> Unfortunately a bug has been introduced in that snapshot that segfault
> BSDi 4.2:
>
> $ gdb htdig htdig.core
> GNU gdb
> This GDB was configured as "i386-unknown-bsdi4.2"...
> Core was generated by `htdig'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /tmp/Search/lib/htdig/libhtnet-3.2.0.so...done.
> Reading symbols from /usr/lib/libz.so...done.
> Reading symbols from /tmp/Search/lib/htdig/libcommon-3.2.0.so...done.
> Reading symbols from /tmp/Search/lib/htdig/libhtword-3.2.0.so...done.
> Reading symbols from /tmp/Search/lib/htdig/libht-3.2.0.so...done.
> Reading symbols from /tmp/Search/lib/mifluz/libhtdb-3.2.0.so...done.
> Reading symbols from /usr/lib/libstdc++.so.1...done.
> Reading symbols from /shlib/libm.so.0.0...done.
> Reading symbols from /shlib/libgcc.so.1...done.
> Reading symbols from /shlib/libc.so.2...done.
> Reading symbols from /shlib/ld-bsdi.so...done.
> #0 global constructors keyed to HtHTTP::_user_agent () at HtHTTP.cc:40
> 40 String HtHTTP::_user_agent = 0;
> (gdb) bt
> #0 global constructors keyed to HtHTTP::_user_agent () at HtHTTP.cc:40
> #1 0x2011c8b7 in __do_global_ctors_aux () at HtHTTPBasic.cc:47
> #2 0x2010dfe9 in _init () from /tmp/Search/lib/htdig/libhtnet-3.2.0.so
> #3 0x200f4a8b in _dl_boot () from /shlib/ld-bsdi.so
> #4 0x5 in ?? ()
> #5 0x8047da4 in ?? ()
> Cannot access memory at address 0x5.
> (gdb) q
> $
Well, I don't know if "revisited" is the right word, as this is not like
any of the previous segfault problems you had. It seems to stem from
shared library constructors, so try configuring with --disable-shared
and see if the problem goes away.
HtHTTP.cc hasn't changed since May 3rd, so any snapshot after April 29
will likely do the same thing. In fact, the particular initialisation
where it's failing has been around much longer, even before 3.2.0b1,
so it is indeed interesting that it's only causing a segfault now.
> By the way, have you determined the cause of slow indexing from the
> profile I posted.
No. As I wrote back on May 14...
What I can't figure out is why there's so many "spontaneous" calls to
regcomp! That seems to be where it's spending almost all of its time
(i.e. in children of regcomp) but the profiling gives no clue as to what
is generating all these calls, as though the function's entry point was
somehow bypassed. Could it be that a stray pointer somewhere is causing
the code to just jump somewhere into regcomp? Does anyone have any ideas/
suggestions about this? I'm afraid I'm out of ideas.
Geoff and I talked about it briefly, but I can't account for the
millions of mysterious calls to regcomp(). However, with the strange
behaviour above with segfaults suddenly appearing, I'm wondering if
it wasn't shared library support all along that was causing problems,
only it wasn't segfaulting before, just mucking up pointers and causing
the code to jump to places it shouldn't.
If you weren't using --disable-shared when you did your profiling,
try it with --disable-shared and see if that changes anything.
--
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
_______________________________________________
htdig-dev mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/htdig-dev
