Stale Objective-C object pointer detection

  • On 13-Apr-08, at 1:06 PM, Greg Titus wrote:
    > The big difference is that in Objective-C, trying to send a message
    > to nil results in a no-op instead of an access violation, so your
    > defensive C++ practice is actually going to tend to mask those same
    > errors in Objective-C and make them harder to track down.

    *smacks forehead*

    Yeah, now that I actually think about it, that would be the effect,
    wouldn't it. Just hadn't made the connection up 'til now, somehow.
    Thank you.

    OK, then, what would an equivalently useful value to set a released
    Objective-C object pointer/ivar to in order to cause any subsequent
    access of it to stop the program immediately? 0xDEADBEEF perhaps?

    --
    Alex Curylo -- <alex...> -- http://www.alexcurylo.com/

    Programming is like sex...
    One mistake and you support it the rest of your life.
  • You want to just leave the pointer alone and turn on NSZombiesEnabled
    when you run your app. Then instead of the object on the other end of
    the pointer being freed, it'll point to a special zombie class which
    will helpfully raise you an exception when you try to send it a
    message. This has the added advantage of being able to more easily see
    what the pointer _used_ to point to, because the zombie has
    information about the original class name.

    - Greg

    On Apr 13, 2008, at 1:35 PM, Alex Curylo wrote:
    >
    > On 13-Apr-08, at 1:06 PM, Greg Titus wrote:
    >> The big difference is that in Objective-C, trying to send a message
    >> to nil results in a no-op instead of an access violation, so your
    >> defensive C++ practice is actually going to tend to mask those same
    >> errors in Objective-C and make them harder to track down.
    >
    > *smacks forehead*
    >
    > Yeah, now that I actually think about it, that would be the effect,
    > wouldn't it. Just hadn't made the connection up 'til now, somehow.
    > Thank you.
    >
    > OK, then, what would an equivalently useful value to set a released
    > Objective-C object pointer/ivar to in order to cause any subsequent
    > access of it to stop the program immediately? 0xDEADBEEF perhaps?
    >
    > --
    > Alex Curylo -- <alex...> -- http://www.alexcurylo.com/
    >
    > Programming is like sex...
    > One mistake and you support it the rest of your life.
    >
    >
    >
    >
  • On 13-Apr-08, at 2:15 PM, Greg Titus wrote:
    > You want to just leave the pointer alone and turn on
    > NSZombiesEnabled when you run your app.

    Huh. I'd actually stumbled across NSDebug.h before, but the
    documentation at the top

    "WARNING: Unsupported API.

    This module contains material that is only partially supported -- if
    at all.  Do not depend on the existance of any of these symbols in your
    code in future releases of this software..."

    sounded to to me an awful lot like "ignore this header". Righty then,
    now I know better. Thanks again!

    --
    Alex Curylo -- <alex...> -- http://www.alexcurylo.com/

    You know you've had a good night when you wake up
    and someone's outlining you in chalk.
  • On Apr 13, 2008, at 3:35 PM, Alex Curylo wrote:
    > OK, then, what would an equivalently useful value to set a released
    > Objective-C object pointer/ivar to in order to cause any subsequent
    > access of it to stop the program immediately? 0xDEADBEEF perhaps?

    Well.. you could do what Greg said and go all NSZombie on it, but you
    have to remember to do that and stuff.

    If you want a total hack, just assign (id) 0x1 to any variable that
    really ought to never be used again or better be initialized before
    being used again.

    If you want to get terribly fancy, you could create your own root
    class that implements (on Leopard) -resolveInstanceMethod: /
    +resolveClassMethod: and logs, then crashes.

    I wrote up some messaging hints here:

    http://www.friday.com/bbum/2008/01/01/objective-c-a-hack-to-log-all-methods
    /

    http://www.friday.com/bbum/2008/01/02/objective-c-logging-messages-to-nil/

    b.bum
  • On Sun, Apr 13, 2008 at 5:33 PM, Alex Curylo <alex...> wrote:
    >
    > On 13-Apr-08, at 2:15 PM, Greg Titus wrote:
    >
    >> You want to just leave the pointer alone and turn on NSZombiesEnabled when
    > you run your app.
    >>
    >
    > Huh. I'd actually stumbled across NSDebug.h before, but the documentation
    > at the top
    >
    > "WARNING: Unsupported API.
    >
    > This module contains material that is only partially supported -- if
    > at all.  Do not depend on the existance of any of these symbols in your
    > code in future releases of this software..."
    >
    > sounded to to me an awful lot like "ignore this header". Righty then, now I
    > know better. Thanks again!

    Unsupported means that you can't rely on it, not that it doesn't work.
    In other words, Apple doesn't wish to be committed to keeping this API
    functional and changeless in all future releases of Mac OS X. You can
    use it without any trouble on your own machine, but if you ship code
    which uses anything from this header then you do so at your own risk.
    Fortunately they're all things which you would generally only use on
    your own machine, which is pretty much the point.

    Mike
previous month april 2008 next month
MTWTFSS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30        
Go to today