On Fri, 29 Oct 1999 09:52:35 -0700, Paul Stillwell wrote:
> I don't think there is a misunderstanding on our part. A simple test to
>determine whether the memory leak is in the LiS stack or in our code would
>be for us to turn off the MSG_TRACE define in LiS. If we undefine MSG_TRACE
>and the memory leak goes away, then that would say that there is a bug in
>the code contained within MSG_TRACE. If the problem does not go away, then
>that would imply there is a problem with our code. So, we undefined
>MSG_TRACE and poof, the memory leak is gone. So that implies that there is
>something in the code defined by MSG_TRACE that isn't right.
MSG_TRACE is defined in <sys/stream.h> and could pollute your name
space. Is the MSG_TRACE symbol is used in your code?
> And why would you ever mark memory as 'free' but leave it on lis_mem_head?
>That is exactly what happens in freehdr. You do not free the message header
>until you have more that 10 message headers allocated. Instead you just
>mark that memory as 'free' and put it on the lis_mdbfreelist. But, it
>doesn't look like it was ever taken off the lis_mem_head. That looks like a
>no-no to me.
This is done for performance. LiS does not have a slab allocator, and
it does not (yet) use the Linux 2.2 slab allocator. Instead kmalloc()
is used to allocate memory. Having a cache of preallocated objects
speeds up the allocation of small mblk_t structures. The memory is
marked free to indicate that these are not leaked memory blocks.
The same technique is used for timer and bufcall control structures.
If LiS is compiled as a kernel module, these lists are freed at module
unload time.
If you compile your code and LiS as kernel modules, all leaked memory
blocks are logged to the kernel log when LiS is unloaded.
Best regards,
Ole Husgaard
[EMAIL PROTECTED]
----------------------- *THE_LIST_HAS_MOVED* -------------------------------
It is now hosted at gsyc.escet.urjc.es.
To (un)subscribe send a mail to <[EMAIL PROTECTED]>
To send a contribution send a mail to <[EMAIL PROTECTED]>
Web archives for lists can be found at http://gsyc.escet.urjc.es/lists
