[Opalvoip-devel] memory leaks, windows

[Vladimir F. <vla...@gm...>]

Hello all,

  I made a test of robustness of my application based on OPAL (using
ptlib+opal revision 25130 from opal svn, that is ptlib 2.9.1 and opal 3.9.1)
and h.261 video codec. I made a call which last for 9 hours and it depleted
all the memory (~1.5GB).

When I did the math, the loss is about 46 KB/s, which is ~360 kbps and that
looks like bitrate for CIF transfer (but it's just a guess).

Are you aware of anything in the code that could cause a memory leaks per
frame ? or nearly per frame ? or memory leaks at all ? Something like
"not-freed" compressed video frames, perhaps ? (I guess you made tests with
valgrind, so you know whether it leaks or not on Linux and that could be the
source of problems on Windows as well)

Unfortunately I'm not very familiar with internal machinery of OPAL nor
PTLIB yet. From what I read and seen so far it looks like :

minimal application usually consists of
- 1 opal manager with
- 2 end points (local and h323)

- after call has been established : 2 connections with 4 streams : video
source/sink, audio source/sink for both connections each belonging to one of
endpoints

so I guess the creation of these classes is done only once (e.g. there is
only 1 instance of them per call (or maybe not, what I'm trying to say is,
that OPAL does not repeatedly creates/destroys connections nor streams per
video/audio frame so this cannot make leaks (definitely not so huge and
permanently increasing)).

So, there should be an internal mechanism (a thread I guess) which do the
magic and sucks data from sources and pushes them to sinks. Which is
responsible for creation and destruction of video frames. I looked at the
code of the plugin and it itself has methods to create/destroy frames,
however I have not found a place where are these methods called.

Therefore I'd like to ask, what part of OPAL is responsible for creation and
destruction of video frames ? Is it completely matter of codec ?

Thank you very much,

Best regards,

 Vladimir Fekete