Hi Stefan!
On Mon, 31 Jul 2006, Stefan Völkel wrote:
> > Okay, I now see in the code, that the debug output is always cut after
> > 100 chars, so this isn't so amazing. But why does privoxy die or at
> > least stop answer requests (sometimes it keeps the TCP port up, but
> > doesn't answer)?
>
> let me check if am still running this patch, might be that I lost this
> one due to a partial reinstallation.
In the meantime I noticed, that privoxy doesn't seem to die every time
but only most times on my amd64 system when reading compressed pages.
If I run privoxy in a debugger, it usually doesn't die.
I tried to run it in combination with the memory debugger valgrind
(which I never used before, so I do not fully know what I did) and
this gives me hints, that there may be a problem with the
freez(csp->iob->buf); call in parsers.c:883:
/* Finally, we can actually update the iob, since the
* decompression was successful. First, free the old
* buffer.
*/
freez(csp->iob->buf);
/* Now, update the iob to use the new buffer. */
valgrind says the following about this code:
==32474== Address 0x535E427 is 1,351 bytes inside a block of size 4,096 free'd
==32474== at 0x4A1B422: free (vg_replace_malloc.c:233)
==32474== by 0x41BDAA: decompress_iob (parsers.c:883)
==32474== by 0x4136BC: pcrs_filter_response (filters.c:1612)
==32474== by 0x415CCD: serve (jcc.c:1422)
==32474== by 0x4F81B1B: start_thread (in /lib/libpthread-2.3.6.so)
==32474== by 0x515C9C1: clone (in /lib/libc-2.3.6.so)
where "1,351" differs from call to call, but this looks strange to me.
Ciao
Roland
