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: "Sean McBride" <email@hidden>
- Date: Wed, 5 Apr 2006 11:16:41 -0400
- Organization: Rogue Research
On 2006-04-05 00:42, John Draper said:
>><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...
Great, MallocScribble and MallocPreScribble have helped you find a bug!
I suggest you leave them on all the time, assuming it doesn't slow
things down too much.
>>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?
I couldn't do it either. :( The idea is the same as guard malloc
though. Guard Malloc replaces the usual implementations of malloc/free
with versions that have features that help catch bugs. For details, see:
<http://developer.apple.com/documentation/Darwin/Reference/Manpages/man3/
libgmalloc.3.html>
Likewise, one could replace new/delete with versions that have special
features. In Classic Mac OS, Metrowerks provided DebugNew which was
just such a thing. But it is now obsolete. I'm not aware of any Mac OS
X replacement. (Though, as new/delete call down to malloc/free, tools
that debug malloc/free are helpful too!) Actually, you could check out
the libstdc++ debug mode:
<http://developer.apple.com/documentation/DeveloperTools/gcc-3.3/libstdc+
+/debug.html>
I don't do much C++ so I'm not sure how helpful it is...
>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.
And you tested them separately on the Mac, not just linux, right?
Might I also suggest you retest them separately using MallocScribble,
MallocPreScribble, guard malloc, etc. That may find something that
didn't show up before.
--
____________________________________________________________
Sean McBride, B. Eng email@hidden
Rogue Research www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
_______________________________________________
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