Re: [Beepcore-c-users] beepcore-c memory purity?

[David C N. <dc...@ad...>]

On Mon, 22 Mar 2004, William J. Mills wrote:
> Well, long ago, we used to run purify on it.  So the initial checkin
> was pretty clean.

How long ago was that, before or after the 0.2 release?

> One of the things that does happen is that there's A couple of thinsg
> that maintain their own free lists of unusued pre- allocated objects.  
> It's possible that's what you are seeing.
> 
> Does the memory usage peak?

It goes pretty high, 300+ MB total size, with RSS climbing to 100+ MB,
over the course of a couple hundred large messages.  So we're not talking
some little tiny buffers here, there's at least something happening
per-message, and quite likely per-frame.  Nothing statically allocated
could account for this kind of growth or total size.  OTOH, it is not
time-based; memory usage does not increase while the system is running
unless messages pass through it.

I have seem memory use sometimes drop a little bit now and then, only to 
rise again beyond its previous peaks as more messages are handled.

I think I have found a leak in my application profile, which could come to 
9K per message that applies to some types of messages, but that is a drop 
in the bucket compared to what I'm seeing.

---

To verify, for sending a chunk my understanding is that you use
bpc_buffer_allocate() to allocate a send buffer and populate it with your
data, and bpc_send ultimately destroys this buffer automatically once it
has been sent.

On the receive side, you get a frame in pro_frame_available which you free
by calling bpc_frame_destroy() when you are done with it.

There are other areas where I am not entirely confident about how memory 
is deallocated, but they are per-profile, per-channel, per-session, etc. 
and are thus not nearly as significant as these are all permanent 
allocations in the current application.

----

One other thing I noticed: it looks like the file of the profile's .cfg 
file is left open indefinitely.  I'd think it ought to be closed as soon 
as it's read.

-------------------------------------------------------
-- David C. Niemi           Adeptech Systems, Inc.   --
-- Reston, Virginia, USA    http://www.adeptech.com/ --
-------------------------------------------------------