Re: [Quickfix-users] Memory Leak

[Oren M. <or...@qu...>]

I looked into this further and the results are truly bizarre.

I was able to duplicate the first 'leak' that you demonstrated (which =20=

as you point out isn't really a leak at all).  The thing is there =20
isn't really anything that is hoarding memory either.

The testing I was doing was with gcc 4.0.1.  I ran a simple test that =20=

sent message from one session to another with an empty fromApp.  I =20
was using a SocketInitiator/SocketAcceptor pair.  As expected, the =20
memory footprint remained constant.  I then added your example of =20
creating a new message with the copy constructor.  In this case, the =20
memory footprint was definitely increasing, like you predicted it =20
would.  Here is where it begins to get weird.

I switched to using a ThreadedSocketInitiator/ThreadedSocketAcceptor =20
pair, and poof, the memory footprint remained constant even with the =20
copy constructor calls.

So we have a situation where the exact same code increases the =20
footprint in one case, but not in the other.  And since there is no =20
increase in footprint with an empty fromApp with both acceptor types, =20=

there isn't a reason they should behave differently.

So, on a hunch I compiled QuickFIX with icc and reran the tests.  =20
Well, you can guess what  happened here, no increase of the memory =20
footprint under any scenario.  Yikes! Looks like a compiler bug!

I don't know the details of your environment, but are you using a =20
SocketInitiator or Acceptor, and if so, can you try switching to the =20
Threaded versions and see how this affects the footprint?

--oren
> Well.  After spending some more time with Purify and valgrind, I am =20=

> starting to think that there is not an actual leak, but more of a =20
> =93hoarding=94 of memory !!!
>
> There is no question that the program grows and grows (as per the =20
> previous posting)  but now I am not convinced that it is because of =20=

> a leak.
>
> Oren, what do you reckon is the normal memory foot print of a =20
> simple quickfix app which just return from fromApp without doing =20
> anything?  Why when I just instantiate a message from a string, =20
> over and over again, the footprint is stable.  When I start using =20
> the copy constructor the foot print grows even though the program =20
> is not really doing anything?  What is it about repeating groups =20
> that could induce this observations?
>
> Both valgrind and purify don=92t detect any significant leak (when =20
> compared to the footprint) when one calls initiator.stop() and then =20=

> exit()=85
>
> I am puzzled and frustrated J
>
> Regards
>
> David