Re: Seeking advice on debugging "real time" programs.
Re: Seeking advice on debugging "real time" programs.
- Subject: Re: Seeking advice on debugging "real time" programs.
- From: j o a r <email@hidden>
- Date: Tue, 4 Apr 2006 21:50:55 +0200
On 3 apr 2006, at 23.19, John Draper wrote:
I've been able to pass VIOP sound remotely, but after a certain
period of
time, it crashes. I think somewhere I'm either not releasing a
handle, or
Cocoa or C++ object, or making unnecesary allocations. I'm also
getting a
"flutter" sound, indicating possible performance or timing
problems. Possibly caused in part by all the memory leaks I'm getting.
What makes you think that there is a memory leak? Leaks usually
doesn't crash your app, unless they're really, really, bad. If you
check your app with "top" while it's running, is it growing more than
what you would expect? How are you crashing?
Using "MallocDebug" is fine when dealing with "not so critical"
timing issues,
but when inside a RTP Thread where timing is everything, these
tools can
slow down the application so much it breaks the timing.
Are these "timing issues" so critical when you're trying to find a
memory leak? I wouldn't expect them to be, unless your code changes
it's behaviour radically when it's slowed down.
* Performance testing (Shark), but don't know what I'm looking
for... :-(
Shark has *great* documentation. Check under the "Help" menu, and the
technotes on developer.apple.com. Make sure that you're running the
latest and greatest.
On 4 apr 2006, at 00.15, David Dunham wrote:
Sure, set MallocStackLogging and then use leaks from the command
line. (You'd set a breakpoint at a spot when you expect memory to
be cleaned up -- in my case at the end of main().)
The "leaks" command line utility doesn't work like that. You can run
it at any time, because it looks for references to _orphaned_ memory,
not just any memory that hangs around when you're done executing. Of
course, the longer you wait, the more orphaned memory you are likely
to see if you have memory leaks, but usually they rear their ugly
little heads much sooner than that.
My suggestion would be:
1) Launch the app in the debugger, with MallocStackLogging=YES.
2) Do whatever you suspect triggers the leaks
3) Stop the app in the debugger (I'm not quite sure that this is
required, but I think it make sense)
4) Run the leaks command line utility
5) Fix the memory leaks, rebuild
6) GOTO #1
Fixing memory leaks is often an iterative process. As soon as you can
identify a leak, fix it and run the app again.
On 4 apr 2006, at 02.49, John Draper wrote:
Right now, I only have a G3 Wall St laptop (First one released with
a Firewire and USB port).
Aouch!
On 4 apr 2006, at 20.01, John Draper wrote:
yes - I intend to do the same thing.... but when I bring up the
console, I get a lot of this...
Looking for devices matching vendor ID=1193 and product ID=8718
Looking for devices matching vendor ID=1193 and product ID=8717
Looking for devices matching vendor ID=1193 and product ID=8718
Looking for devices matching vendor ID=1193 and product ID=8717
Looking for devices matching vendor ID=1193 and product ID=8718
What is this? and why am I getting this? This keep outputting
constantly,
making it very difficult to see any other console output.
Google knows! :-)
I looked at my source code, but what is this?
"_ZN5resip10infoServerC4Ev" I don't have such
a class or function. How can I interpret this? I know the
previous one... the code is...
I don't know. C++ name mangling?
On 4 apr 2006, at 20.06, John Draper wrote:
Is there anyone on this list experienced in "thread safety"? I
looked at the Apple App Notes on it,
and every AppNote I could find on the subject.
If you don't feel comfortable around threads, don't use them!
j o a r
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden