Re: Debugging xfree() (WAS: , in the URL)

mån 2003-03-24 klockan 12.49 skrev Mihalis Tsoukalos:
> Dear Henrik,
>
> as far as I understand, I think that the kind of errors I get from running
> "valgrind ./squid -DNYCd3" are not fatal.

invalid write of size 1 is always fatal when given on memory allocations
done by the program, and certainly in the case you indicated.

You allocated 23 bytes, but tried to write at least 24 bytes into the
returned memory area. 24 is more than 23 and will not fit in the
returned memory area, and as a result you get memory corruption by
overwriting internal structures of malloc and maybe other structures
(how much is overwritten depends on the actual size of the data you try
to copy into the too small memory block)

If you are just overwriting with a single byte then quite often you will
be lucky and the extra byte will fit inside the padding done by malloc
(all sizes are rounded up to an multiple of 8 bytes), but if the size
allocated depends on some external data then certain patterns may cause
fatal corruption even if you write as little as a single byte beyond the
allocated area. These patterns are those where the allocated size fits
exactly for malloc() and no padding is needed (even number of 8 bytes
allocated).

> I also have the feeling that our changed version of squid is running better
> with the -N parameter. The problem is when squid runs without the -N
> parameter.

There is no noticeable difference in Squid operation when running with
or without the -N option. The only difference is that when you use -N
stdout and stderr is still connected to the terminal, in all other
aspects the process is identical to that of a child process when not
using -N.

-- 
Henrik Nordstrom <hno@squid-cache.org>
MARA Systems AB, Sweden