Re: How to get the name of a method at runtime?
Re: How to get the name of a method at runtime?
- Subject: Re: How to get the name of a method at runtime?
- From: Jean-Daniel Dupas <email@hidden>
- Date: Sun, 9 Mar 2008 23:55:43 +0100
ObjectAlloc and other Apple developement tools already record memory
calls (retain, release, alloc, ...) full trace. You really doesn't
need to reinvent the wheel to find leaks.
Le 9 mars 08 à 23:17, Tony Becker a écrit :
Agreed, I forgot to add that warning.
I was using it to put fingerprints against alloc calls, retain/
release cycles, and some other methods so I could track down memory
leaks and some less then compliant code in debug builds.
It should not end up in release builds.
On Mar 9, 2008, at 6:06 PM, Bill Bumgarner wrote:
On Mar 9, 2008, at 2:59 PM, stephen joseph butler wrote:
On Sun, Mar 9, 2008 at 4:45 PM, Tony Becker <email@hidden>
wrote:
If you're on Leopard, there is a new backtrace(3) call.
If you're on Tiger, it's a little more complex...
You can use the compiler function
(long)__builtin_return_address(0)
to find the address of your caller. Alas, there is no
__builtin_return_symbol()
Interesting. The manpage for backtrace mentions dladdr, which is
available on 10.4. Maybe you can use that instead of launching atos.
Particularly, I'm looking at the dli_sname member.
You really *do not* want to write code that relies upon stack
introspection for normal use.
Debugging tool? Go for it.
Two reasons:
(1) From a design perspective, relying upon identification of the
calling method is just... odd. And fragile. It also greatly
limits the reusability of code and makes all kinds of refactoring
operations rather dangerous as it vastly increases the complexity
of the dependency graph on any given method name.
(2) Stack introspection is inherently architecture specific and
very fragile. There is no guarantee that the caller of a method
is an Objective-C method in and of itself nor, even, that the
calling function actually has a fully formed stack frame. In the
presence of optimization, registers and local variables may be
reused and such reuse is not necessarily limited from blasting self
and _cmd of the calling frame.
b.bum
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden