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 00:42:57 -0700
Sean McBride wrote:
On 2006-04-04 11:06, John Draper said:
I did get the MallocDebug to work, but my tests didn't come up with any
substantial reason why the
program crashes after a few minutes of running.
I once had a similar task. A realtime product that had some kind of
memory corruption bug. Back then we didn't have guardmalloc, but as you
know that slows things down too much. We did have the various
MallocDebug environment variables, but they also (mostly) slowed things
down too much. But I do suggest trying as many of them as you can,
maybe one at a time. I'm talking about these suckers, btw:
<http://developer.apple.com/releasenotes/DeveloperTools/MallocOptions.html>
WOW - A whole new document Ihaven't read yet... yummy yummmy... Ok, After
reading this, I tried a few things... One thing I tried is why when I
do this...
m_MyExtIP = new char(100);
and I turned on MallocScribble and MallocPreScribble to see if it put in the
0x55 bytes, but I still see...
0x64000000
Instead of
0x555555555
Why?
Is this because the new char() doesn't use Malloc? For some reason,
it only
allocates 16 bytes, causing the run-over.
For instance... I have these two statements...
m_MyExtIP = new char(100); returns 0x66516d0
m_MyInIP = new char(100); returns 0x66516e0 <---- Certainly
this is WRONG!!!
According to the C++ manual I have, this is supposed to allocate 100
bytes for the
string as a character array. Am I using this wrong?
If you suspect problems with C++ object allocations, you may be able to
use a lightweight new/delete replacement. I'm not sure which to
recommend these days.
I would have NO idea how to do that. What do you mean by replacement?
Where would I get this replacement? and why would I want to replace it?
We were using CodeWarrior and had some success
with its DebugNew, but I can't recommend it now, its not thread safe,
and maybe doesn't even work with gcc. I haven't tried it, but you might
look at Howard Hinnant's simple_mem_debug, though it's old by now I guess:
<http://groups.google.com/group/codewarrior.mac/tree/browse_frm/thread/
688428e11d0b0079/e94f660f4817a06e?rnum=1&q=howard+hinnant+memory&_done=%
2Fgroup/codewarrior.mac/browse_frm/thread/688428e11d0b0079%
2F4bb302c9281aa46a?lnk=st&q=howard+hinnant+memory&rnum=3%
26#doc_e94f660f4817a06e>
Or you could write your own.
I wouldn't even know where to begin. I'm an application programmer, not
a system OS designer.
The next thing I did, which you won't like, is remove code until the
problem goes away, add code till it comes back, repeat ad nauseam.
That's how I ended up finding the cause of our memory corruption, and
the cause was a QuickTime bug! argh!
Not practical in my case. Besides I did test everything seperately,
it's when
I put them together I get the hangup.
If you could remove enough of your code such that you no longer have a
realtime requirement, you can then test those parts of your code with
guard malloc. Maybe its your UI code that is trashing memory, and that
can be tested and debugged independently of the realtime bits.
Already did that - it wouldn't get integrated it it wasn't tested
seperately.
I'm putting together...
JRTPLIB - a C++ Lunix originally RTP stack and UDP transporter.
MTCoreAudio - an Objective C wrapper around Apple's lower level Core
Audio
resiprocate - A SIP stack ported to the Mac from Linux, written in C++.
None of these were designed to work with each other. Each one is a seperate
Library or framework. each one works on it's own data structures.
Each one was tested seperately.
The problem is a thread lock in JRTPLIB hangs up when the mutex is locked.
The specific thread is the one that listens for the RTP UDP packets on the
socket using the POSIX network socket call "recvfrom". A Mutex lock is
called, and it hangs up there. Regardless if any data is present in the
socket
when "recvfrom" is called. The sequence is...
Allocate autorelease pool
Mutex.lock();
< Do the listen part which calls the processing part which calls
Core Audio.
Mutex.unlock();
Release the Autorelease pool.
I keep things nice and nested. I thought about putting the Autorelease pool
allocation AFTER the "Lock" and the Release of it BEFORE the unlock.
But then after thinking about it, I thought it was right as I have it now.
I try to keep my threads simple. I have two distinct CoreAudio threads, one
for input device, and one for output device. I never touch any data used by
the CoreAudio threads.
I thought about enclosing them with...
@synchronized(anObject)
{
// Perform any operations that depend on exclusive access.
[anObject modify];
}
// The mutex is now released.
But was told the RTP had it's own independent thread. Although not using
Cocoa style NSThreads.
Still doesn't explain why the Lock hangs up.
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