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: John Draper <email@hidden>
- Date: Wed, 05 Apr 2006 18:48:02 -0700
j o a r wrote:
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?
Because I already found 4 of them. Luckily, none of these leaks didn't
occurr as I was processing
compressed audio frames...
Leaks usually doesn't crash your app, unless they're really, really,
bad.
Well - none of these were (whew).
If you check your app with "top" while it's running, is it growing
more than what you would expect?
Good question.... never throught about checking it that way... are you
saying the memory indicated
by the running process is that used by the application? If so, what
zone is it displaying? Everything?
Do threads also show up in "top", or do they become part of the
application when shown in the "top"
command?
How are you crashing?
Well - the latest news on that is (I think) a thread safety issue. I
don't suppose you are
familiar with the MTCoreAudio framework written by Mike?
I'm using the JRTPLIB RTP stack in a VIOP application (using SIP). It
uses jthread and jmutex modules,
a C++ wrapper around the Procedural POSIX thread support. It crashes
when I try to perform a "Lock()"
at the start of the thread loop. In my code, I call the MTCoreAudio to
"play" the sound to the speaker.
I'm still trying to figure this out.... I have about 5 things to try
today on this. One of them is to use
the @synchronize Objective C directive. I have no clue how to use it,
but the docs seem to indicate
it might work.
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?
To find out if I'm "leaking" inside a tight real-time loop - YES!! very
critical... but
thanx to the wonderful help and references from the other participants
in this
list, I've been able to determine that I'm not allocating anything in
the tight loop,
but had to be sure, as it was calling the MTCoreAudio methods to play
the sound.
I wouldn't expect them to be, unless your code changes it's behaviour
radically when it's slowed down.
It does, especially when trying to run it while Guard malloc is on. It
took me a long time
to fiddle around with how to use it. Through experimentation, I found
I also had to
turn on MallocStackLogging to get Guard Malloc to work.
* 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.
yea - well, I just realized I don't have CHUD installed on the G4
machine I'm using, and I need to get
Ver 4.1.1 (which is not very easy to find on the Apple site anymore).
Someone on this list sent
me a URL, but (sigh) it was wrong... so I'm back to square one. As to
why I'm not using the
newer X-Code system, is because I don't have hardware that supports
it. I'm working for
an offshore company (not surprising - with all this oursourcing going
around), and mired in
Bureaucracy... Hopefully someday, and I'm trying very hard not to let
it stop me from finishing
this project.
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.
But I still have to turn on MallocStackLogging, right?
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.
Done that.
2) Do whatever you suspect triggers the leaks
Done that... I used mallocDebug and it found all of them.
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
So - I can use the debugger to control my App, and stop it wherever I
want, then at any
point I would use the shell's "leaks" utility... I suppose that would
work, because I have to
pass it my process ID, and even while running from within the debugger,
that process is
showing up in the "ps" or "top".... so even through the APP may be
paused or stopped,
the "leaks" still can probe it?
5) Fix the memory leaks, rebuild
Done that. Still crashes... but at least I know what is NOT causing
the crash, and
when you're like me, forced to play a lot of "guessing games" and
making "probable
assumptions", it's at least progress... perhaps 0.00001% progress, but
progress
just the same.
Right now, I only have a G3 Wall St laptop (First one released with
a Firewire and USB port).
Aouch!
Thats what they ALL say (sigh) - Hopefully someday... keeping my
fingers crossed
while I wait and wait and wait - build times are about 15 mins (compile
ONE module)
and link (I cannot use Zero Link - don't think it's possible in my
situation).
I'm currently visiting a friend who has a G4... it's an amazing
improvement.... and
I still have to use X-Code 1.5 though.
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! :-)
Google does? About all I find from Google are zillions of other people
asking the
same question. I have a USB Headset plugged into the G4 and I think this is
causing it, not google does NOT have an answer on how to stop it, so if
anyone
else who happens to read this list has an answer, I sure would like to know
how to stop it.
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?
Is that what this is? name mangling? I don't suppose I could trouble
you for any links
or references to this?
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!
Can't say I blame you - Unfortunately the library I use, uses them. I
haven't got much of a
choice in the matter.
So - I have this MTCoreAudio framework - which is probably NOT thread
safe, and without it,
I can never hope to deliver my App on time, so how can I make something
I know nothing about
thread safe?
I've already read: Introduction to Multithreading Programming Topics
from the docs...
It mentions the use of the "synchronized" directive and some example is
shown
below, and I have some questions on this? But is this the list to do it in?
I'll post the relevant parts of this to the CocoaDev mailing list as well,
but want to present it here, is that OK?
Below shows how to use the "synchronized" directive.
- (void) myMethod:(id)anObject
{
@synchronized(anObject)
{
// Perform any operations that depend on exclusive access.
[anObject modify];
}
// The mutex is now released.
}
My questions are: the "anObject" - Is this the NSMuteableArray pointer
I want
to keep "thread safe"?
Can ANY object be "anObject" and have it be "protected"? Could it be my
MTCoreAudio delegate?
Where is this method normally defined? In my Controller? Or is this
called from
within a thread? Obviously, the docs don't tell me this... Argghh -
more Guessing
games...
I read and re-read that document, and It's still totally vague and
incomplete.
Why don't they use more then a single example.
John
_______________________________________________
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