Re: Solved? Cocoa/Java - NSCoding woes...
Re: Solved? Cocoa/Java - NSCoding woes...
- Subject: Re: Solved? Cocoa/Java - NSCoding woes...
- From: janderson <email@hidden>
- Date: Sat, 1 Mar 2003 00:29:37 -0500
PublicLook,
I believe that there may be more going on here (that is with memory
errors associated with NSUnarchiver) than just direct references to
deallocated objects.
My code, which is pure Cocoa, was crashing at the end of my GUI "event
loop" which unarchived a custom class object (reporting error signal
10 or 11).
I know that the default application autorelease pool is flushed at the
end of this "event loop."
Although my code makes no to attempt access the unarchived object when
it crashes, (I even called release on the unarchived object within the
loop), my problem was solved by retaining it (as you recommended).
This suggests to me that it is NSUarchiver itself that is crashing my
program when it is autoreleased because it then tries to deallocated
the unarchived object (which had already been deallocated by me) .
John Anderson
"...but that's not going to happen. You can sooner expect a tall
talking broccoli stick to offer to mow your lawn for free."
--Dan Rather, quoted in the Los Angeles Times , March 28, 1996.
On Friday, Feb 28, 2003, at 22:30 America/Detroit, publiclook wrote:
>
It is necessary to retain objects that are unarchived. The
>
NSUnarchiver retains the objects it unarchives, but when the
>
unarchiver itself is deallocated, it releases all of the objects it
>
has retained. If the unarchiver was the only object retaining an
>
unarchived object, the unarchived object will also be deallocated when
>
the unarchiver releases it.
>
>
I don't know how the Java bridge works, but if unarchived objects are
>
not retained by the bridge and they are not retained explicitly then
>
they will be deallocated when the unarchiver is deallocated and you
>
will get signal 10 or 11 when the deallocated objects are accessed.
>
>
You made your errors go away by not letting the unarchiver be
>
deallocated so it continues to retain the unarchived objects. The
>
better solution is to retain the unarchived objects that you want to
>
keep and let the unarchiver be deallocated normally. That will
>
probably free up lots of temporary objects and other clutter too.
>
>
On Friday, February 28, 2003, at 06:27 PM, Rams wrote:
>
>
> I believe I have discovered the source of my signal 6, 10, and 11's.
>
> It looks like I've been bitten by the GC goblin, however the object
>
> that is causing the trouble puzzles me a bit. Keeping a reference to
>
> the NSUnarchiver does away with the mysterious errors, but why it is
>
> causing a problem in the first place mystifies me a bit. By the time
>
> it crashes the app, I would assume that I had long been done with the
>
> thing but this doesn't appear to be the case. Is there some closure
>
> method that I should be calling after unarchiving an object?
>
>
>
>
>
> --
>
>
>
> There are only 10 kinds of people in this world... those who
>
> understand binary and those who don't
>
> _______________________________________________
>
> cocoa-dev mailing list | email@hidden
>
> Help/Unsubscribe/Archives:
>
> http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
> Do not post admin requests to the list. They will be ignored.
>
_______________________________________________
>
cocoa-dev mailing list | email@hidden
>
Help/Unsubscribe/Archives:
>
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.