• 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: OmniObjectMeter and PB/gdb
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: OmniObjectMeter and PB/gdb


  • Subject: Re: OmniObjectMeter and PB/gdb
  • From: Paul Williamson <email@hidden>
  • Date: Wed, 07 Aug 2002 01:20:02 -0700

At 09:44 PM 8/6/2002 -0700, Timothy J. Wood wrote:
1)
- Start the vict^H^H^H^H target using OOM
- Start a debugger session (I use gdb in Terminal, but PB should work)
- Do NOT start the process in gdb, but instead figure out the pid of the target and do:
attach pid

I could've sworn that didn't work yesterday, but today it does. Thanks!

Probably I was confused by a couple of things:

First, I didn't realize that the target program automatically breaks when you attach to it with gdb. Nothing runs again until you tell it to. I guess that makes sense.

Second, I didn't realize that OOM can't run, not even its UI, when the target program isn't running. This makes OOM+gdb a much less appealing combination that I had hoped. I wanted to paw around in the OOM displays while my program sat at a breakpoint, so I could carefully step through the consequences of each part of the program.

I guess that OOM is trying to minimize its data collection, so it only retrieves the information it needs to update the display. And that implies that OOM can't update the display in any useful way when it can't collect new data. And it must be gathering data by communicating with routines in the running target process. Oh, well.

I can't figure out how to get a gdb running in PB without also running the target program.

2) (This is what I was doing...)
- Link the OmniObjectMeterFramework as per the instructions in the OOM manual
- Launch the process in gdb
- Launch OOM and it should automatically connect

I was hoping to avoid this, but I just tried it and ...

First, there's an error in the help file. It says to include <OmniObjectMeterFramework/OOMPublic>, but that doesn't exist. It's actually <OmniObjectMeterFramework/OOMPublic.h>.

Second, the procedure given for creating what the help file calls a "link" but is actually an alias does not work. It runs afoul of permissions. Bypassing the permissions problem allows the alias to be created.

Third, the alias doesn't work. The build fails, complaining that it can't open the framework. Getting rid of the alias and creating an actual link (from Terminal with "ln -s") allows the program to find the framework and run. (Disclaimer: maybe I'm confused about the alias and the link, too. I'm a refugee from embedded systems and this is the first Mac OS alias I've ever created.)

Finally, OOM successfully connects with the target and gets data, hurrah. But it works the same way as with the first procedure: the OOM UI freezes when the target program is paused. Too bad. However, this procedure does have the advantage that you can do it from within Project Builder.

Thanks for your help!

-Paul
email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: OmniObjectMeter and PB/gdb
      • From: "Timothy J. Wood" <email@hidden>
References: 
 >OmniObjectMeter and PB/gdb (From: Paul Williamson <email@hidden>)
 >Re: OmniObjectMeter and PB/gdb (From: "Timothy J. Wood" <email@hidden>)

  • Prev by Date: Accessors
  • Next by Date: Re: enough of accessors - how about private method naming conventions in the real world?
  • Previous by thread: Re: OmniObjectMeter and PB/gdb
  • Next by thread: Re: OmniObjectMeter and PB/gdb
  • Index(es):
    • Date
    • Thread