Re: [bug] MemBuf and using as string

From: Henrik Nordstrom <>
Date: Tue, 16 Apr 2002 02:39:27 +0200

Found why we haven't seen this before.. the old MemPools always cleared
freed memory, but the chunked pools sometimes skip this.. there is the
following condition:

memPoolPush(MemPool * pool, void *obj)
    void **Free;
    if ((pool->obj_size % 2048) != 0)
        memset(obj, 0, pool->obj_size);

Now, having pools who don't waste time on clearing their freed content
is a good thing, but it then needs to be defined, not guessed from the

I will make memBufAppend() \0 terminate the data, and replace the
condition above with a comment that we should figure out a way to avoid
this on the pure data buffer pools..


Henrik Nordstrom wrote:
> There is several places in the code using MemBuf as a string blindly
> assuming there is a \0 terminator after the data, but MemBufAppend()
> apparently do not guarantee this...
> Identified so far:
> debugObj()
> log_mime_hdrs
> but there probably is more..
> Now to the question: Should we audit the code to make sure it properly
> deals with this by appending the \0 where required before using it as a
> string with the slight risk of accidently introducing a \0 in output
> data, or modify MemBuf to always \0 terminate the data outside of the
> accounted data size?
> I am a bit surprised we haven't seen this before.. I detected it by
> noticing there was HTML error content in cache.log on some "Forwarding
> loop detected" error messages (debugObj).
> Regards
> Henrik
Received on Mon Apr 15 2002 - 18:36:39 MDT

This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:15:10 MST