htdig-dev

Re: [htdig-dev] 3.2.0b5??

[Geoff H. <ghu...@ws...>]

> 2. *Everyone* puts time into trying to locate/fix the compression bug

I've certainly been putting in what time I have, but as I'm not having
much luck reliably reproducing it, it's a bit difficult for me.

Further pointers from you and/or Neil would really help in my search.

-Geoff

[htdig-dev] Re: 3.2.0b5??

[Lachlan A. <lh...@us...>]

Greetings all,

I apologise for the rudeness of my previous email, and thanks for not=20
flaming me :)  I didn't mean to sound unappreciative of the efforts=20
that everyone is putting in -- I was just having a bad day...  Thanks=20
Jim, Neal and Geoff for replying.

The trouble that I'm having seems to come from the list of free disk=20
pages getting corrupted.  What do other people get when they run
  make TESTS=3Dt_htdig_local check
after applying the patch at
  http://home.iprimus.com.au/lachlan_andrew/htdig/freelist.patch
?  The output I get (Mandrake8.2, gcc 3.1) is in
  http://home.iprimus.com.au/lachlan_andrew/htdig/debug.first.gz
and
  http://home.iprimus.com.au/lachlan_andrew/htdig/debug.second.gz
(The output differs because  make check  doesn't clean up after=20
itself.)

My hunch is that this (and the infinite recursion problem earlier)=20
come from the fact that the new "transparent compression" routines=20
are not re-entrant, but are being called recursively.  They call=20
original "allocate page" routines.  These "allocate page" routines=20
sometimes need to write dirty memory pages, which uses the on-the-fly=20
compression.  If anyone can think of a way to avoid this recursion=20
(or to make the compression code properly reentrant) please post it.

Thanks,
Lachlan

On Sat, 12 Apr 2003 02:41, Geoff Hutchison wrote:
>
> I've certainly been putting in what time I have, but as I'm not
> having much luck reliably reproducing it, it's a bit difficult for
> me.
>
> Further pointers from you and/or Neil would really help in my
> search.

[htdig-dev] Compression bug(s)

[Lachlan A. <lh...@us...>]

Greetings all,

Among other problems, I think I've found a (slow) memory leak in=20
mp_cmpr.c -- does anyone know where the memory allocated using
      CDB___memp_cmpr_alloc_chain(dbmfp->dbmp, bhp, BH_CMPR_POOL);
is (or should be) freed?

Thanks,
Lachlan

On Sat, 12 Apr 2003 02:41, Geoff Hutchison wrote:

> Further pointers from you and/or Neil would really help