• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Seeking advice on debugging "real time" programs.
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


  • Follow-Ups:
    • Re: Seeking advice on debugging "real time" programs.
      • From: j o a r <email@hidden>
References: 
 >Seeking advice on debugging "real time" programs. (From: John Draper <email@hidden>)
 >Re: Seeking advice on debugging "real time" programs. (From: David Dunham <email@hidden>)
 >Re: Seeking advice on debugging "real time" programs. (From: j o a r <email@hidden>)

  • Prev by Date: Current Project Version: Change does not cause rebuild?
  • Next by Date: Re: Seeking advice on debugging "real time" programs.
  • Previous by thread: Re: Seeking advice on debugging "real time" programs.
  • Next by thread: Re: Seeking advice on debugging "real time" programs.
  • Index(es):
    • Date
    • Thread