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, 12 Apr 2006 14:37:47 -0700
j o a r wrote:
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.
Yea - I know - one of the pitfalls of programming the Mac, but I suppose
other platforms can
also experience this problem.
That said, my question was more on why you got the idea that leaks
was part of the problem being discussed here.
I had originally thought that, because if I had some serious leaks ( I
always do), from within the
40 ms real time programming, I had originally thought that I would fill
up the heap pretty fast.
so when my App was chunking along just fine, then crashed, I had
originally thought it might
have been the heap getting full.
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. \
I have no more leaks, thanx to the pointers I've gotten from other list
members, reading the tech notes,
and trying things.
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!
I have.
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*?
I wish I know, and am open to suggestions on how to find out.. anyone
got any ideas?
Is it a signal, and if so which one?
It appears to be hung up in the JRTPLIB "listen" thread at the moment.
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.
Oh, I didn't know about this one. I'll check it out.
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?
This was suggested to me, without further explanation. All I know
about it, is what I read in
the Tech notes and docs, and we all know how useless these docs are when
they (whoever wrote
them) don't have the common decency to at least put a few more examples
in them. They fail
to give any details at all on what this "object" is that is passed to
the @synchronize.
You need to know exactly what you're trying to accomplish, or you'll
end up creating more problems.
Agreed - and explains why I'm here on the list, so I can learn what to
do to deal with this problem.
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.
yes - I agree. And I'm learning it now. The books recommended by the
other list members have been
ordered from Amazon, and I figure they should come in the mail really soon.
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.
Right... but I would need to launch my application from X-Code right?
Since I have the
"MallocStackLogging" set in the Executeable.
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.
Ok, Got it.
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 mean MTCoreAudio is using receiveQueue and this is a NSMuteableArray
of type NSData.
I am not knowingly changing this datum. And since I'm always crashing
when I try to
access the datum to play the sound, I suspected this MIGHT be the
problem, and
as usual when dealing with programming the Mac, everything is almost a
guessing game
anyway... lots of trial and error envolved... "Try this - try that"
I think it would help if you described how you're using threads, and
what system / third party libraries / frameworks you're using.
I thought I did that, so one more time...
I'm developing a VIOP Sip phone for the mac. Because Apple does NOT
support SIP or have
any API's to it, I've had to go out and find them. After many months
of research, I came
to the conclusion that using "resiprocate" for the SIP stack, and
JRTPLIB for the RTP
and transport layer (sending the compressed audio frames). each of
these libraries
are self contained, and for my learning purposes, I moved these
libraries into X-Code
as seperate targets of the .a variety (static BSD).
Both resipricate and JRTPLIB uses the lower level posix "pthread" C
functions. Resip
adds their own C++ wrappers around the "pthread" and JRTPLIB wraps
around a totally
different version which also calls the "pthread" - All of these threads
are seperate,
with their own Mutex's. So it is highly unlikely one thread would be
stomping on data
used by the others.
MTCoreAudio uses NSThreads, one for input and one for output devices.
Again, these are
totally self contained, and should not interfere with each other.
JRTPLIB C++ objects are created and a RTPSession object (which I
sub-class) has a
method called "OnPollThreadStep" which contains a loop to listen for
incoming packets.
These are processed, and eventually winds of calling the MTCoreAudio
method to
output the sound to the speaker.
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).
I'm getting responses from there, but you are right, I'll try to keep
the focus on this list
towards X-Code issues, so please guys, if there is any tools to help
me nail down this
problem, please let me know.
I would like to know if it's possible to put a "Watch" variable so when
an Object is changed,
like when I add another item to a NSMuteableArray, it would break into
the debugger.
Can that be done with X-Code?
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.
Ok. I thought so also.
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.
Which is exactly what I'm doing.
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.
No - I'm developing it on a G4 Dual processor machine, so it is a
multi-CPU machine.
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