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: Thu, 6 Apr 2006 09:48:08 +0200
On 6 apr 2006, at 03.48, John Draper wrote:
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...
Sure, if checking for leaks is not part of your development process,
you will *always* have leaks.
That said, my question was more on why you got the idea that leaks
was part of the problem being discussed here. While tracking down and
fixing leaks is always a good thing to do, you seem to have more
serious problems at hand, and if they are not caused by leaks, it's
probably best to avoid spending too much time on learning how to deal
with leaks, and fixing leaks, until they've been resolved.
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?
Everything. There are some disclaimers on how to interpret the
statistics reported by top, but it's a very nice tool to use for
quickly and easily getting an overview of CPU and memory usage. You
should add it to the set of tools you use regularly!
Do threads also show up in "top", or do they become part of the
application when shown in the "top"
command?
Threads show up (See the #TH column), and from a memory perspective
they're always "part of the application".
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.
Right, but again - *how*? Is it a signal, and if so which one? If you
run in GDB when you crash, type "thread apply all backtrace" (or "t a
a bt") to see what your threads are up to, and where you crash.
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.
Work in what way? You need to know exactly what you're trying to
accomplish, or you'll end up creating more problems.
I don't want to sound to harsh here, and I don't want to claim that
I've always known everything about the technologies that I've worked
with. But, unlike learning a new API and mucking around with new data
types, functions, and concepts that you might not know much about, I
would say that you have little chance of fixing your threading
problems (if that's what it is) without a better understanding on
what's going on.
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?
At least if you want to see the backtraces to your malloc events in
the leaks report.
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...
Correct.
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?
Just like with GDB, and as David mentioned earlier in this thread,
you can pass it the _name_ of the process instead of the PID. Very
convenient.
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?
When you say that it's not thread safe, what do you mean? I think it
would help if you described how you're using threads, and what
system / third party libraries / frameworks you're using. I kind of
doubt that this mailing list is appropriate for that discussion
though (I see that you've created a thread on CocoaDev, and that's
probably a good place).
My questions are: the "anObject" - Is this the NSMuteableArray
pointer I want to keep "thread safe"?
It could be.
Can ANY object be "anObject" and have it be "protected"? Could it
be my MTCoreAudio delegate?
Yes, if that would make sense.
Where is this method normally defined? In my Controller? Or is
this called from within a thread?
I don't think that the simple Yes/No, or very generalized, answers
that you're looking for exists.
Obviously, the docs don't tell me this... Argghh - more Guessing
games...
Multithreading is difficult. It's perhaps not a very big topic on the
conceptual level, but it's not something that you should expect to
learn all about from a single technote. Unfortunately it's also one
of those things that you need to get 100% correct, or not use at all.
Being "mostly" thread safe is basically worthless. If you're not
confident that you understand what it's all about and how it applies
to your project, you need to spend time on it until you do.
Also, please note that if you have problems with threading, having
your code run fine on a particular machine is no proof that it's
going to work fine on some other machine. In particular, a lot of
threading problems only show up when you're running on multi-CPU
machines. It sounds like you're developing on single-CPU machines
only? That's rather dangerous when working with multithreaded code.
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