Memory Leak in Mac Client

[Grozni Majmun]

It looks like there is a memory leak in the mac client.

Take a look at this thread over in the MacNN forums.

[Shaktai]

I posted information in the Client bug thread up top.

[Brian the Fist]

I will try it out on our Mac and see what happens. There is no leak on Windows and no leak on Linux and haven't really run it for days on other platforms. Is it possible the leak is in a Mac OSX system call? Otherwise, the leak should be on ALL unixes (since the code is almost identical on all of them).

[Scotttheking]

It looks like it's specific to OSX.
My linux boxes don't have it.

[Shaktai]

My windows boxes don't have it either. Only the Mac OS-X boxes seem to run into it. Quitting the client and restarting once every day or 2 seems to bed a good temporary work around.

[GOLDENBALLSAINTYORK]

Is That An Apple MAC!
with ice and soda..
twist of lemon..:sleepy:

[Brian the Fist]

Ok, it seems to leak on our 'build' Mac as well. If someone can suggest/provide some free memory-leak detection software (e.g. ccmalloc, purify, etc.) for OS x I can locate the leak. Probably cannot fix it though since it is most likely in a system call, but cannot say for sure until I know where it is. I know next to nothing about OS X so you MAC fans please direct me to some memory leak detectors if possible please.

[sklepp]

I think the command is /usr/bin/leaks
and in the man pages Man leaks

[sklepp]

Do we get a new Client now?

Couldn't resist....

[sklepp]

OK, I waited and no feed back, so for those who haven't tested it
the leaks program, which is run like this
leaks PID
in place of the PID put the process ID of the folding prog, located with top
then return and what you will get is a continual stream of leaks
the prog is leaky from start to finish.
it looks like this but runs unil end of prog::
Leak: 0x02919bd0 size=14 string '619410'
Leak: 0x02919bc0 size=14 string '2220038'
Leak: 0x02919bb0 size=14 string '6417000'
Leak: 0x02919ba0 size=14 string '726089'
Leak: 0x02919b90 size=14 string '5646647'
Leak: 0x02919b80 size=14 string '917054'
Leak: 0x02919b70 size=14 string '3639000'
Leak: 0x02919b60 size=14 string '1051119'
Leak: 0x02919b50 size=14 string '17068888'
Leak: 0x02919b40 size=14 string '59279625'
Leak: 0x02919b30 size=14 string '3358442'
Leak: 0x02919b20 size=14 string '9304800'
Leak: 0x02919b10 size=14 string '88260'
Leak: 0x02919b00 size=14 string '89520'
Leak: 0x02919af0 size=14 string '22653288'
Leak: 0x02919ae0 size=14 string '5558330'
Leak: 0x02919ad0 size=14 string '35746380'
Leak: 0x02919ac0 size=14 string '16464743'
Leak: 0x02919ab0 size=14 string '43182999'
Two sad faces for this one!

[sklepp]

Just imagine how much faster the Mac would be without these errors!!!
We might be in the lead even....

[Brian the Fist]

A good try, but I cannot get leaks to give me any more info than it gave you, even when I compile with -g (debug information) and with the -cycle option and MallocStackLogging=1 (using setenv).

Can someone instruct me on how to get the symbols out of this so I can see a proper stack trace to the leaks? Pretend for a moment that Im dumb and need expliciit, clear step-by-step instructions. Thanks.

[Brian the Fist]

And BTW, leaks seems to report memory leaks in just about EVERY process, not just foldtraj - is this expected??

[sklepp]

Yep, alot of other programs but with 'NSCFString or NSCFNumber'
Instances, don't know. It says carbonization has a lot to do with it.
there might be more in the Dev Center at Apple.
Be nice if they got involved here and pulled Motorolas resources in too.

[sklepp]

Brian the Fist, have you tried 'GDB'?
The Apple DeBugger, in dev tools can get stack traces +.

[sklepp]

GDB can get the symbols out to for the traces,
almost forgot to mention.
sorry

[Shaktai]

The leak doesn't seem to be quite as bad in the newest client, but it is still there.

[sklepp]

Yep, but it does seem to clear itself out and keeps itself at a lower memory
usage rate unlike the previous client have to say it is much better.

[Brian the Fist]

There has been very little change to the executable between versions so I have no idea what affected the memory leaks. But cant complain I guess

Anyways, GDB cannot be combined lith 'leaks' as far as I can tell so I don't see how it will help. I am trying to interpret the output from leaks and get a stack trace from inside leaks.

Any thoughts?

[sklepp]

Try this instead of leaks ::
MallocDebug.app
it's in the dev tools and works on the memory leaks in a graphical way.
Here is some of what it does ::
MallocDebug is a utility for understand how an application uses memory. You can use MallocDebug to measure and analyze all allocated memory in an application or to measure the memory allocated since a given point in time. MallocDebug also detects memory leaks.

This one should do it for you..