[Leopard] Debugging GC

  • Hi!

    I am currently working on my first GC-enabled application.

    When I start the application I get the following console output in
    Xcode:

    HoudahSpot2(20753,0xb0103000) malloc: free_garbage: garbage ptr =
    0x105e7c0, has non-zero refcount = 1
    HoudahSpot2(20753,0xb0103000) malloc: free_garbage: garbage ptr =
    0x10696e0, has non-zero refcount = 1

    What can I do about this? How does one debug this?

    Best,
    Pierre Bernard
    Houdah Software s.à r.l.

    ---
    Pierre Bernard
    http://www.bernard-web.com/pierre
    http://www.houdah.com
  • This happens to me when I use one of the built-in template images from
    interface builder like NSStopProgressFreestandingTemplate. If I remove
    the template image and use one of my own images, no GC errors. A radar
    was filed a few months ago.

    On 10/29/07, Pierre Bernard <i_love_my...> wrote:
    > Hi!
    >
    > I am currently working on my first GC-enabled application.
    >
    > When I start the application I get the following console output in
    > Xcode:
    >
    > HoudahSpot2(20753,0xb0103000) malloc: free_garbage: garbage ptr =
    > 0x105e7c0, has non-zero refcount = 1
    > HoudahSpot2(20753,0xb0103000) malloc: free_garbage: garbage ptr =
    > 0x10696e0, has non-zero refcount = 1
    >
    > What can I do about this? How does one debug this?
    >
    > Best,
    > Pierre Bernard
    > Houdah Software s.à r.l.
    >
    > ---
    > Pierre Bernard
    > http://www.bernard-web.com/pierre
    > http://www.houdah.com
    >
  • On Oct 29, 2007, at 4:59 AM, Pierre Bernard wrote:
    > I am currently working on my first GC-enabled application.

    Excellent!

    > When I start the application I get the following console output in
    > Xcode:
    >
    > HoudahSpot2(20753,0xb0103000) malloc: free_garbage: garbage ptr =
    > 0x105e7c0, has non-zero refcount = 1
    > HoudahSpot2(20753,0xb0103000) malloc: free_garbage: garbage ptr =
    > 0x10696e0, has non-zero refcount = 1
    >
    > What can I do about this? How does one debug this?

    This means that something somewhere had CFRetain()'d something and not
    CFRelease()'d it before the collector determined that the something --
    the collector is not limited to Objective-C objects -- is garbage
    eligible for collection.  It is generally harmless.

    While -retain/-release/-autorelease are no-ops under GC, CFRetain()
    and CFRelease() are not.

    In other words, this is a bug in the Apple supplied frameworks.
    There is a radar tracking it and it'll be fixed.

    b.bum
  • Wow, you are right. That's it. I was using "NSAddTemplate".

    Pierre

    On Oct 29, 2007, at 4:04 PM, Tom Pusateri wrote:

    > This happens to me when I use one of the built-in template images from
    > interface builder like NSStopProgressFreestandingTemplate. If I remove
    > the template image and use one of my own images, no GC errors. A radar
    > was filed a few months ago.
    >
    > On 10/29/07, Pierre Bernard <i_love_my...> wrote:
    >> Hi!
    >>
    >> I am currently working on my first GC-enabled application.
    >>
    >> When I start the application I get the following console output in
    >> Xcode:
    >>
    >> HoudahSpot2(20753,0xb0103000) malloc: free_garbage: garbage ptr =
    >> 0x105e7c0, has non-zero refcount = 1
    >> HoudahSpot2(20753,0xb0103000) malloc: free_garbage: garbage ptr =
    >> 0x10696e0, has non-zero refcount = 1
    >>
    >> What can I do about this? How does one debug this?
    >>
    >> Best,
    >> Pierre Bernard
    >> Houdah Software s.à r.l.
    >>
    >> ---
    >> Pierre Bernard
    >> http://www.bernard-web.com/pierre
    >> http://www.houdah.com
    >>

    ---
    Pierre Bernard
    http://www.bernard-web.com/pierre
    http://www.houdah.com
  • On Oct 29, 2007, at 8:33 AM, Bill Bumgarner wrote:

    > On Oct 29, 2007, at 4:59 AM, Pierre Bernard wrote:
    >> I am currently working on my first GC-enabled application.
    >
    > Excellent!
    >
    >> When I start the application I get the following console output in
    >> Xcode:
    >>
    >> HoudahSpot2(20753,0xb0103000) malloc: free_garbage: garbage ptr =
    >> 0x105e7c0, has non-zero refcount = 1
    >> HoudahSpot2(20753,0xb0103000) malloc: free_garbage: garbage ptr =
    >> 0x10696e0, has non-zero refcount = 1
    >>
    >> What can I do about this? How does one debug this?
    >
    > This means that something somewhere had CFRetain()'d something and
    > not CFRelease()'d it before the collector determined that the
    > something -- the collector is not limited to Objective-C objects --
    > is garbage eligible for collection.  It is generally harmless.
    >
    > While -retain/-release/-autorelease are no-ops under GC, CFRetain()
    > and CFRelease() are not.
    >
    > In other words, this is a bug in the Apple supplied frameworks.
    > There is a radar tracking it and it'll be fixed.

    It sounds like the garbage collector is also acting as a leak
    detector! That's a useful feature :)

    Although, if retain/release/autorelease are no-op'ed but CFRetain and
    CFRelease are not, won't that cause problems in that regard? e.g. if
    I have some code that creates an NSString and passes it to an OS
    library that takes a (toll-free-bridged) CFString, my calls to update
    its refcount will be ignored, but the OS library calls to update the
    refcount will be honored… so I can envision many different scenarios
    where refcounts could easily get munged up.
  • On Oct 29, 2007, at 10:27 AM, John Stiles wrote:

    > Although, if retain/release/autorelease are no-op'ed but CFRetain
    > and CFRelease are not, won't that cause problems in that regard?
    > e.g. if I have some code that creates an NSString and passes it to
    > an OS library that takes a (toll-free-bridged) CFString, my calls to
    > update its refcount will be ignored, but the OS library calls to
    > update the refcount will be honored… so I can envision many
    > different scenarios where refcounts could easily get munged up.
    >
    It's not clear what the problem is -- you seem to be confused.

    Provided that you -- or the framework -- balance your CFRetains and
    CFReleases, it Just Works.

    mmalc
  • On Oct 29, 2007, at 11:15 AM, mmalc crawford wrote:

    >
    > On Oct 29, 2007, at 10:27 AM, John Stiles wrote:
    >
    >> Although, if retain/release/autorelease are no-op'ed but CFRetain
    >> and CFRelease are not, won't that cause problems in that regard?
    >> e.g. if I have some code that creates an NSString and passes it to
    >> an OS library that takes a (toll-free-bridged) CFString, my calls
    >> to update its refcount will be ignored, but the OS library calls
    >> to update the refcount will be honored… so I can envision many
    >> different scenarios where refcounts could easily get munged up.
    >>
    > It's not clear what the problem is -- you seem to be confused.
    >
    > Provided that you -- or the framework -- balance your CFRetains and
    > CFReleases, it Just Works.

    Well, with GC, retain counts are not needed, since objects are not
    collected by their retain counts but rather by when they are
    unreferenced. So there's no real problem per se. No actual memory leaks.
    But if CFRetain(obj) will bump a refcount, while [obj release] will
    fail to decrement it, it seems like it will be a common problem that
    objects will have incorrect refcounts when they are collected.
    It is perfectly legal to adjust a toll-free-bridged object's refcount
    using either the CF calls (which work) or the NSObject calls (which
    no-op).
  • On Oct 29, 2007, at 11:26 AM, John Stiles wrote:

    > Well, with GC, retain counts are not needed, since objects are not
    > collected by their retain counts but rather by when they are
    > unreferenced. So there's no real problem per se. No actual memory
    > leaks.
    > But if CFRetain(obj) will bump a refcount, while [obj release] will
    > fail to decrement it, it seems like it will be a common problem that
    > objects will have incorrect refcounts when they are collected.
    >
    CFRetain and -retain are no longer symmetrical, as are not CFRelease
    and -release...

    > It is perfectly legal to adjust a toll-free-bridged object's
    > refcount using either the CF calls (which work) or the NSObject
    > calls (which no-op).
    >
    ... you should balance CFRetain with CFRelease.  That's it.

    mmalc
  • On Oct 29, 2007, at 11:34 AM, mmalc crawford wrote:

    > On Oct 29, 2007, at 11:26 AM, John Stiles wrote:
    >
    >> Well, with GC, retain counts are not needed, since objects are not
    >> collected by their retain counts but rather by when they are
    >> unreferenced. So there's no real problem per se. No actual memory
    >> leaks.
    >> But if CFRetain(obj) will bump a refcount, while [obj release]
    >> will fail to decrement it, it seems like it will be a common
    >> problem that objects will have incorrect refcounts when they are
    >> collected.
    >>
    > CFRetain and -retain are no longer symmetrical, as are not
    > CFRelease and -release...
    >
    >
    >> It is perfectly legal to adjust a toll-free-bridged object's
    >> refcount using either the CF calls (which work) or the NSObject
    >> calls (which no-op).
    >>
    > ... you should balance CFRetain with CFRelease.  That's it.

    If the semantics of these calls and/or their legality in various
    contexts has changed, I guess this is the first I've heard of it.
    I guess that makes sense since I'm not planning on adopting GC in the
    near future ;)
  • On Oct 29, 2007, at 1:34 PM, mmalc crawford wrote:

    >
    > On Oct 29, 2007, at 11:26 AM, John Stiles wrote:
    >
    >> Well, with GC, retain counts are not needed, since objects are not
    >> collected by their retain counts but rather by when they are
    >> unreferenced. So there's no real problem per se. No actual memory
    >> leaks.
    >> But if CFRetain(obj) will bump a refcount, while [obj release] will
    >> fail to decrement it, it seems like it will be a common problem
    >> that objects will have incorrect refcounts when they are collected.
    >>
    > CFRetain and -retain are no longer symmetrical, as are not CFRelease
    > and -release...
    >
    >
    >> It is perfectly legal to adjust a toll-free-bridged object's
    >> refcount using either the CF calls (which work) or the NSObject
    >> calls (which no-op).
    >>
    > ... you should balance CFRetain with CFRelease.  That's it.

    It use to be that if you called a CFCopy style routine, you could
    return the result via autorelease, something like:

    - (id) getSomethingFromCarbon
    {
    CFFooReference cffoo = CFCopyFooWithBar(5);
    return [(id)cffoo autorelease];
    }

    (assuming CFFooReference was one of the bridged objects).

    So what is the correct idiom now?

    Glenn Andreas                      <gandreas...>
      <http://www.gandreas.com/> wicked fun!
    quadrium | prime : build, mutate, evolve, animate : the next
    generation of fractal art
  • On Oct 29, 2007, at 11:36 AM, John Stiles wrote:

    > On Oct 29, 2007, at 11:34 AM, mmalc crawford wrote:
    >
    >> On Oct 29, 2007, at 11:26 AM, John Stiles wrote:
    >>
    >>> Well, with GC, retain counts are not needed, since objects are not
    >>> collected by their retain counts but rather by when they are
    >>> unreferenced. So there's no real problem per se. No actual memory
    >>> leaks.
    >>> But if CFRetain(obj) will bump a refcount, while [obj release]
    >>> will fail to decrement it, it seems like it will be a common
    >>> problem that objects will have incorrect refcounts when they are
    >>> collected.
    >>>
    >> CFRetain and -retain are no longer symmetrical, as are not
    >> CFRelease and -release...
    >>
    >>
    >>> It is perfectly legal to adjust a toll-free-bridged object's
    >>> refcount using either the CF calls (which work) or the NSObject
    >>> calls (which no-op).
    >>>
    >> ... you should balance CFRetain with CFRelease.  That's it.
    >
    > If the semantics of these calls and/or their legality in various
    > contexts has changed, I guess this is the first I've heard of it.
    > I guess that makes sense since I'm not planning on adopting GC in
    > the near future ;)

    I think mentioning CFMakeCollectable/NSMakeCollectable is appropriate
    here. Those methods help you transition an object with CFRetain
    semantics into a context that would normally -[NSObject release] it
    while taking garbage collection into consideration.

    Jon Hess


  • On 10/29/07, glenn andreas <gandreas...> wrote:
    > It use to be that if you called a CFCopy style routine, you could
    > return the result via autorelease, something like:
    >
    > - (id) getSomethingFromCarbon
    > {
    > CFFooReference cffoo = CFCopyFooWithBar(5);
    > return [(id)cffoo autorelease];
    > }
    >
    > (assuming CFFooReference was one of the bridged objects).
    >
    >
    > So what is the correct idiom now?

    -(id)getSomethingFromCarbon
    {
      CFFooReference cffoo = CFCopyFooWithBar(5);
      return [NSMakeCollectable(cffoo) autorelease];
    }

    This does the right thing under bot GC and non-GC. Under GC, the
    NSMakeCollectable decrements the retain count and makes the object
    collectable, while the autorelease is a no-op. Without GC, the
    NSMakeCollectable is a no-op, and the autorelease functions as it
    always has.

    --
    Clark S. Cox III
    <clarkcox3...>
  • On Oct 29, 2007, at 10:27 AM, John Stiles wrote:
    > On Oct 29, 2007, at 8:33 AM, Bill Bumgarner wrote:
    >> On Oct 29, 2007, at 4:59 AM, Pierre Bernard wrote:
    >>> I am currently working on my first GC-enabled application.
    >> Excellent!
    >>> When I start the application I get the following console output in
    >>> Xcode:
    >>>
    >>> HoudahSpot2(20753,0xb0103000) malloc: free_garbage: garbage ptr =
    >>> 0x105e7c0, has non-zero refcount = 1
    >>> HoudahSpot2(20753,0xb0103000) malloc: free_garbage: garbage ptr =
    >>> 0x10696e0, has non-zero refcount = 1
    >>>
    >>> What can I do about this? How does one debug this?
    >> This means that something somewhere had CFRetain()'d something and
    >> not CFRelease()'d it before the collector determined that the
    >> something -- the collector is not limited to Objective-C objects --
    >> is garbage eligible for collection.  It is generally harmless.
    >>
    >> While -retain/-release/-autorelease are no-ops under GC, CFRetain()
    >> and CFRelease() are not.
    >>
    >> In other words, this is a bug in the Apple supplied frameworks.
    >> There is a radar tracking it and it'll be fixed.
    > It sounds like the garbage collector is also acting as a leak
    > detector! That's a useful feature :)
    >

    I glossed over some details.

    Specifically, what is happening is that an object is being CFRetain'd
    after the collector has already thrown it into the garbage list;  has
    already determined that it is collectable.

    (Keeping in mind that "object" does not mean "objective-c object" but
    "chunk of allocated memory which may or may not be an obj-c object").

    This can happen because something is allocating or CFRetain'ing memory
    during finalization and then not CFRelease'ing it.  Bad code, no coffee!

    The collector quite explicitly does not support resurrection and
    retaining-without-releasing-during-finalization effectively leads to a
    resurrection situation.

    > Although, if retain/release/autorelease are no-op'ed but CFRetain
    > and CFRelease are not, won't that cause problems in that regard?
    > e.g. if I have some code that creates an NSString and passes it to
    > an OS library that takes a (toll-free-bridged) CFString, my calls to
    > update its refcount will be ignored, but the OS library calls to
    > update the refcount will be honored… so I can envision many
    > different scenarios where refcounts could easily get munged up.

    Yes, that can happen, but it doesn't cause a problem in correctly
    written code, nor does it make anything worse in incorrectly written
    code.

    Specifically, if you have a strong reference to an object, that object
    will not be collected.  If an object is CFRetained, it will not be
    collected.  If CFRelease is called and the reference count drops to
    0, the object will be eligible for collection (it may not be collected
    right as the reference count drops to zero).    If you destroy the
    last scanned reference to an object but there is still a retain count,
    the object will not be collected until sometime after the release.

    b.bum
  • On Oct 29, 2007, at 12:18 PM, glenn andreas wrote:
    > It use to be that if you called a CFCopy style routine, you could
    > return the result via autorelease, something like:
    >
    > - (id) getSomethingFromCarbon
    > {
    > CFFooReference cffoo = CFCopyFooWithBar(5);
    > return [(id)cffoo autorelease];
    > }
    >
    > (assuming CFFooReference was one of the bridged objects).
    >
    > So what is the correct idiom now?

    It depends on if you are writing pure-GC or dual mode code.

    In either case, you could:

    - (id) getSomethingFromCarbon
    {
    CFFooReference cffoo = CFCopyFooWithBar(5);
    return [NSMakeCollectable((id)cffoo) autorelease];
    }

    This will work for both GC and non-GC modes.  However, if you are
    writing an application, I would suggest that you turn on "GC Only"
    mode.  This eliminates the relatively small amount of overhead
    incurred by the need for code to run in both GC or non-GC modes.

    In that case, you would eliminate the -autorelease:

    - (id) getSomethingFromCarbon
    {
    CFFooReference cffoo = CFCopyFooWithBar(5);
    return NSMakeCollectable((id)cffoo);
    }

    You can also use CFMakeCollectable() -- same as NSMakeCollectable()
    but with CF typed parameter and return value.

    There is an excellent Garbage Collection Programming Guide included
    with Xcode 3.0 that explains all of this and a lot more.

    b.bum
  • On Oct 29, 2007, at 12:18 PM, glenn andreas wrote:

    >> ... you should balance CFRetain with CFRelease.  That's it.
    >
    >
    > It use to be that if you called a CFCopy style routine, you could
    > return the result via autorelease, something like:
    >
    > - (id) getSomethingFromCarbon
    > {
    > CFFooReference cffoo = CFCopyFooWithBar(5);
    > return [(id)cffoo autorelease];
    > }
    >
    > (assuming CFFooReference was one of the bridged objects).
    >
    >
    > So what is the correct idiom now?

    The correct idiom is now (following my own style, sorry):

    - (id)somethingFromCarbon {
        CFFooReference foo = CFCopyFooWithBar(5);

        return [NSMakeCollectable(foo) autorelease];
    }

    CFMakeCollectable and its sibling NSMakeCollectable will:

    * Under GC, invoke CFRelease() to balance the CFCreate/CFCopy and
    return their argument.
    * Under non-GC, just return their argument.

    The only difference between CFMakeCollectable and NSMakeCollectable is
    the return type; CFMakeCollectable returns a CFTypeRef while
    NSMakeCollectable returns an id (eliminating a cast, as in your code
    above).

    Under garbage collection, the final CFRelease of an object DOES NOT
    immediately cause that object to be collected, it simply makes it
    eligible for collection once all strong references to it are gone.
    Thus as long as the object is still referenced from an object-type
    instance variable (that hasn't been marked as __weak), a register, the
    stack, or a global variable, it will stay around.

    When working with garbage collection, CFRetain and CFRelease can be
    useful when you want to guarantee that an object stick around while
    you can't guarantee there are strong references to it.  One good
    example is if you pass an object pointer as a sheet's (void *)context
    parameter -- its (void *) type means it's not necessarily going to act
    as a strong reference.

    So you can CFRetain your object before passing it as the sheet's
    context, and CFRelease it at the end of your sheetDidEnd:...
    callback.  Thus even though bringing up a sheet returns control to the
    main run loop, and the collector may run a number of times before the
    user finishes working in the sheet, your object will stick around
    until the sheet is done and the -sheetDidEnd: callback is fired even
    though the sheet's context may be the only place that references it.

      -- Chris
  • On Oct 29, 2007, at 5:10 PM, Chris Hanson wrote:

    >> So what is the correct idiom now?
    >
    > The correct idiom is now (following my own style, sorry):
    >
    > - (id)somethingFromCarbon {
    > CFFooReference foo = CFCopyFooWithBar(5);
    >
    > return [NSMakeCollectable(foo) autorelease];
    > }
    >
    Since a couple of people have said the same thing now, I think it may
    be worth pointing out that they're looking at this from the
    perspective of a framework developer who has to write mixed-mode code
    (code that has to support both managed memory and garbage collected
    environments).

    For application developers, I'll reiterate Bill's earlier comments:

    Choose either GC or non-GC and stick with your choice.  The
    implementation of your somethingFromCarbon method would then look like:

    - (id)somethingFromCarbon {
        CFFooReference foo = CFCopyFooWithBar(5);

        return NSMakeCollectable(foo);
    }

    (NSMakeCollectable takes a CFTypeRef as a parameter.)

    mmalc
  • On 30 Oct 2007, at 00:33, mmalc crawford wrote:

    > On Oct 29, 2007, at 5:10 PM, Chris Hanson wrote:
    >
    >>> So what is the correct idiom now?
    >>
    >> The correct idiom is now (following my own style, sorry):
    >>
    >> - (id)somethingFromCarbon {
    >> CFFooReference foo = CFCopyFooWithBar(5);
    >>
    >> return [NSMakeCollectable(foo) autorelease];
    >> }
    >>
    > Since a couple of people have said the same thing now, I think it
    > may be worth pointing out that they're looking at this from the
    > perspective of a framework developer who has to write mixed-mode
    > code (code that has to support both managed memory and garbage
    > collected environments).

    Also, if I understand Bill's posts on xcode-dev correctly, mixed-mode
    code won't run on Tiger because the compiler will generate calls to
    functions that don't exist there.

    Presumably that means that a dual-mode framework will need a separate
    Tiger version (assuming Tiger compatibility is a requirement, which it
    commonly will be at the moment).

    Kind regards,

    Alastair.

    --
    http://alastairs-place.net
  • On Oct 30, 2007, at 5:12 AM, Alastair Houghton wrote:
    > Also, if I understand Bill's posts on xcode-dev correctly, mixed-
    > mode code won't run on Tiger because the compiler will generate
    > calls to functions that don't exist there.

    That is correct.

    > Presumably that means that a dual-mode framework will need a
    > separate Tiger version (assuming Tiger compatibility is a
    > requirement, which it commonly will be at the moment).

    Also correct.

    Having worked on a little bit of dual mode code, I can say
    unequivocally that I would either choose to target my App / Framework
    to Leopard / GC Only or I would chose to go non-GC for Tiger
    compatibility.

    Supporting dual mode is a pain.

    (Personally and keeping in mind that I'm a somewhat atypical
    developer, I would choose Leopard / GC Only.)

    b.bum
  • For an example, see <http://homepage.mac.com/mmalc/CocoaExamples/GCCF.zip>.

    This is not an official sample, but I'd like to get feedback on its
    usefulness (or otherwise).
    There's a fair amount packed into a fairly small volume of code.  It
    illustrates Obj-C 2 properties (including, coincidentally, making a
    read-only public property privately read/write), garbage collection
    for CF objects, zeroing weak references (including NSPointerArray),
    and CFStringTokenizer as a bonus.

    mmalc
  • Hi,

    let me jump in. We are moving most of our code to GC, so far this is
    going well.
    Do you confirm these behaviors also apply to other types such as
    CGColor and the likes (not only CF...) ?

    Thanks,

    Raphael

    On 02 Nov 2007, at 08:11, mmalc crawford wrote:

    > >.
    >
    > This is not an official sample, but I'd like to get feedback on its
    > usefulness (or otherwise).
    > There's a fair amount packed into a fairly small volume of code.  It
    > illustrates Obj-C 2 properties (including, coincidentally, making a
    > read-only public property privately read/write), garbage collection
    > for CF objects, zeroing weak references (including NSPointerArray),
    > and CFStringTokenizer as a bonus.
    >
    > mmalc
  • Does anyone know if this big has been fixed yet? I am assuming not
    because I see it when I use NSAddTemplate in a really simple app.

    On Oct 29, 2007, at 11:47 AM, Pierre Bernard wrote:

    > Wow, you are right. That's it. I was using "NSAddTemplate".
    >
    > Pierre
    >
    > On Oct 29, 2007, at 4:04 PM, Tom Pusateri wrote:
    >
    >> This happens to me when I use one of the built-in template images
    >> from
    >> interface builder like NSStopProgressFreestandingTemplate. If I
    >> remove
    >> the template image and use one of my own images, no GC errors. A
    >> radar
    >> was filed a few months ago.
    >>
    >> On 10/29/07, Pierre Bernard <i_love_my...> wrote:
    >>> Hi!
    >>>
    >>> I am currently working on my first GC-enabled application.
    >>>
    >>> When I start the application I get the following console output in
    >>> Xcode:
    >>>
    >>> HoudahSpot2(20753,0xb0103000) malloc: free_garbage: garbage ptr =
    >>> 0x105e7c0, has non-zero refcount = 1
    >>> HoudahSpot2(20753,0xb0103000) malloc: free_garbage: garbage ptr =
    >>> 0x10696e0, has non-zero refcount = 1
    >>>
    >>> What can I do about this? How does one debug this?
    >>>
    >>> Best,
    >>> Pierre Bernard
    >>> Houdah Software s.à r.l.
    >>>
    >>> ---
    >>> Pierre Bernard
    >>> http://www.bernard-web.com/pierre
    >>> http://www.houdah.com
    >>>
    >
    > ---
    > Pierre Bernard
    > http://www.bernard-web.com/pierre
    > http://www.houdah.com
    >
    >

    --
    Mike Nowak
    Center for Health Communications Research
    The University of Michigan
    http://chcr.umich.edu
  • On Dec 22, 2007, at 2:39 PM, Mike Nowak wrote:
    > Does anyone know if this big has been fixed yet? I am assuming not
    > because I see it when I use NSAddTemplate in a really simple app.

    It is not fixed yet in any released version of Mac OS X.

    b.bum
previous month october 2007 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 31        
Go to today