Re: Tricks for debugging run-time bundles
Re: Tricks for debugging run-time bundles
- Subject: Re: Tricks for debugging run-time bundles
- From: Yves Poissant <email@hidden>
- Date: Sun, 2 Apr 2006 15:03:32 -0700
I've been having this issue for a long while too. Exactly like you describe.
If I place a breakpoint in the dylib, the debugger will break there but it
will not step into. I agree, this can make debugging bundles quite tedious.
I still don't know how to make the debugger step into the bundle code
though. Sorry. But I sympathize.
My "trick" is to keep breakpoints at the entry of stepped into functions.
Those breakpoints are disabled except when I know I'm ready to step into it.
Then I enable the breakpoint and the debuger breaks into it and I can
continue stepping through the function.
Another issue I've been having which I think is related, is that the
variables pane will not expand the list of members of classes that are
declared inside the dylib. I wonder if you observe this too.
Yves Poissant
www.hash.com
----- Original Message -----
From: "Tron Thomas" <email@hidden>
To: "Paul Forgey" <email@hidden>
Cc: <email@hidden>
Sent: Sunday, April 02, 2006 11:41 AM
Subject: Re: Tricks for debugging run-time bundles
> It has been a while since I looked at this behavior so I don't remember
> a lot of detail. I do believe that the problem happens every time, so
> it very well might be 100% reproducible. I can't remember if prebinding
> is disabled for these bundles. It very well may be. If I can create a
> scenario that I can submit as a bug I will do so. In the mean time I
> was wondering what people on this mailing list know about that could
> help someone work around this problem.
>
> Paul Forgey wrote:
>> It sometimes happens to me with shared libraries loaded at load time
>> (with prebinding turned off). I haven't thought to reproduce the
>> problem with run time loaded libraries, but I'll bet it's the same
>> problem. At least you found a way to reproduce this 100% then? If
>> so, please file a bug report. This has been making our Darwin porting
>> absolutely hell to do.
>>
>> On Apr 1, 2006, at 7:35 PM, Tron Thomas wrote:
>>
>>> I work on a project that loads several dynamic library bundles at run
>>> time. I'm finding it impossible to debug code in these bundles using
>>> either Xcode or GDB from the command line. When I place break point
>>> in the code, the debugger will break as expected. However when I try
>>> to step through the code, the debugger will react as if I chose to
>>> continue execution. This make it next to impossible to observe what
>>> the code is doing.
>>>
>>> I'm wondering what other people who may have encountered this type of
>>> problem know about trick and techniques that can make the debugger
>>> more useful in this situation.
>>>
>
>
> _______________________________________________
> 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
>
_______________________________________________
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