Re: application halts at __dyld_gdb_dyld_state_changed?
Re: application halts at __dyld_gdb_dyld_state_changed?
- Subject: Re: application halts at __dyld_gdb_dyld_state_changed?
- From: Jim Ingham <email@hidden>
- Date: Fri, 25 Jun 2004 10:31:48 -0700
The way gdb works, every time the target application hits a breakpoint,
one of the first things gdb does is to remove all the breakpoints that
it has placed in the application, and put the original instructions
back in their place.
In this case, the target hits the "notify gdb about shared library
events" breakpoint and gdb goes to remove the breakpoints. But by the
time we get the notification, the memory your plugin occupies has
already been unmapped, so we can't put the original instructions back.
And we are reacting a little too strongly to the error.
We should just check the list of libraries when we get this
notification before we try to fix up the breakpoints and not try to
reinsert ones into unloaded bundles. Could you file a bug on this? If
you have an example that you can send us that would be great, but do
file the bug even if you can't cons up one easily.
In the meantime, if you make sure to remove all the breakpoints by hand
before the bundle gets unloaded, you should be able to follow the app
through to shutdown successfully.
Jim
On Jun 25, 2004, at 8:36 AM, Jeremy Todd wrote:
Hi Jared,
That's interesting that it's during debugging only. I am not using Fix
& Continue and I looked for other debugging-related features which
might be responsible (Zero Link) and disabled them to no avail.
In my case it becomes an issue because I can't get a clean shutdown
from the host application when debugging, and this might mask other
bugs in my plugin preventing a clean shutdown.
Jeremy
On Jun 25, 2004, at 9:46 AM, Jared Watts wrote:
Hi,
Just in the last several days I have also experienced the same exact
problem in relation to CFBundles & CFPlugIns. It only occurs during
debugging (evident from the 'gdb' within the call stack) so it is not
too much of an issue - but could really be an issue for those who
have plug-ins unloading/loading on the fly while trying to debug.
Have you tried disabling Fix & Continue?
Regards,
Jared Watts.
On 25/06/2004, at 8:59 AM, Jeremy Todd wrote:
Hi,
I'm writing an audio plug-in as a Mach-O bundle using Xcode 1.2. I'm
trying to figure out what's causing the following behavior:
The host calls CFBundleUnloadExecutable to unload my plugin, and
then I just get the spinning wait cursor. If I pause the debugger,
the call stack is always:
#0 0x8fe160fc in __dyld_gdb_dyld_state_changed
#1 0x8fe13538 in __dyld__dyld_unlink_module
#2 0x90205500 in _CFBundleDYLDUnloadBundle
#3 0x901ecdd8 in CFBundleUnloadExecutable
... (host-specific call stack)
The debugger console says:
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
Cannot remove breakpoints because program is no longer writable.
It might be running in another process.
Further execution is probably impossible.
and "step instruction" doesn't seem to move the instruction pointer.
Does this behavior sound familiar to anyone? I'm not quite sure how
to proceed in debugging it since it's unclear to me what state the
process is in when the above happens.
Thanks for any help,
Jeremy
iZotope, Inc.
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.