• 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:58:06 -0700

David Dunham wrote:

On 4 Apr 2006, at 11:01, John Draper wrote:

You can find leaks by setting the MallocStackLogging environment variable, but this does take time (and memory).


Yes, of course you can remove it later. Though it's easiest to simply uncheck it in that dialog, so you can turn it on again as needed. (In my normal work, I leave it on so I can check for leaks as fancy takes me, since the performance penalty isn't noticeable.)


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


1. You don't use the console for this, you use the terminal

When I launch the application from the finder, the only way I can see NSLog output
is through the Console, and NOT the terminal, right? At least it works that
way on MY mac.


2. That's probably your scanner driver. Google for that string.

I did - just got a lot of others asking the same question. Most mentioning something about a driver. Could it be that I don't have a USB driver on the G4 Mac I'm using with this Plantronic head set (USB)?


This looks like "leaks" but without a stack trace, so perhaps with a release build.


I have NO CLUE what you're talking about.... could you elaborate on that? Do you
mean this is output from a release build? I looked at the stack trace, I just didn't
send it.


Release builds often have symbols stripped. The stack trace is the interesting part, it tells you where memory was allocated.

Call stack: [thread 8bd7]: | 0x0 | _dyld_start | _start | main | 0x92eba25c | 0x92ecbbe8 | 0x92eba3f4 | 0x92e3b55c | 0x92ee42f8 | 0x92df28bc | 0x90a2e750 | -[mySipController awakeFromNib] | - [SipBridge initWithController:] | resip::infoServer::infoServer() | _ZN5resip10infoServerC4Ev | operator new(unsigned long) | malloc | malloc_zone_malloc


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...


Looks like a mangled name, but C++filt isn't unmangling it...

Someone else mentioned that... so why wouldn't the C++ filter unmangle it? If I click on the File Icon it brings up a totally unrelated C++ file.

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.


Did you turn on MallocGuardEdges, MallocScribble, MallocPreScribble? These are environment variables you can set via Xcode (or a terminal session).

Yes - I did all that. I added most of them, so I just Check them when I want to activate them.
It Did find a buffer overrun problem, but after fixing that, it didn't fix the Mutex.Lock() hang
problem



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.


Try <http://lists.apple.com/mailman/listinfo/mt-smp>

Thanx, I just joined the list - waiting for authentication mail to arrive. usually takes several hours from past experience.

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: David Dunham <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: 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: John Draper <email@hidden>)
 >Re: Seeking advice on debugging "real time" programs. (From: David Dunham <email@hidden>)

  • Prev by Date: Re: Seeking advice on debugging "real time" programs.
  • Next by Date: Re: A Note on your ADC Confidentiality Agreement
  • 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