|
From: Lachlan A. <lh...@us...> - 2003-04-15 11:58:23
|
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. |