Okay, we've resolved this issue in our code at this point. We had a situation 
where a controller object was being instantiated within our MainMenu.nib. When 
that controller's init method was called it was loading another nib, and it was 
an object in that nib (or maybe lots of them, who knows?) that was being freed 
before we could retain it in our applicationDidFinishLaunching: method in the 
controller.

We removed the controller instance from the MainMenu.nib and are instantiating 
it separately in code (which is probably better anyway) and are no longer 
crashing.

Doug Simons

P.S. No stupid company disclaimer this time -- I'll try to remember to delete 
it in the future. :-)

On Mar 18, 2010, at 2:24 AM, Fred Kiefer wrote:

> Just in case my last mail wasn't clear enough on that point: All you
> have to do to get your application working again with the current NIB
> loading code is to add a setter method that retains its argument.
> And for us it would be important to have an example of how it is failing
> without that setter.
> 
> Fred
> 
> Am 17.03.2010 20:16, schrieb Fred Kiefer:
>> I don't expect to see much differences between Windows and X11 on NIB
>> loading. If you could provide me with an stripped down example I would
>> try to have a look at what goes wrong there.
>> 
>> I'm already investigating an issue with the new code when loading a NIB
>> file that Wolfgang prepared for Ink. But there things seem to be the
>> other way around. Object are retained while loading that shouldn't be.
>> 
>> What you cannot expect in the short run is a revert of this code. If we
>> start that there will be no stopping. The intermediate code was proven
>> wrong and it had issues for Wolfgang. Now the new code, which is the old
>> one, should be correct as far as we know, but it may uncover issues with
>> NIB loading that had been previously hidden. I think it is better to
>> track this issues down. Hiding issues wont help. Take a look at the hack
>> Greg added some time ago into NSClipView to have it retain the cursor
>> twice when loading it from a NIB file. This was not only wrong, it also
>> hid the fact that the NSCursor un-archiving was broken.
>> 
>> I am really willing to help you here, but for that I will need some code
>> to work with that clearly shows this problem (and is proven to work on
>> Apple).
>> 
>> Fred
>> 
>> PS: Have we talked about your stupid disclaimer before? Is there a way
>> to turn it off when sending mails to this mailing list?
>> 
>> 
>> Am 17.03.2010 18:19, schrieb Doug Simons:
>>> Unfortunately, this change (Fred's commit in r29223) has broken our
>>> ported Cocoa application (at least on Windows -- haven't had time to
>>> check on Linux yet). At least some objects in our nib files are now
>>> freed after the nib loads, and our application crashes when trying to
>>> access them. Reverting NSBundleAdditions.m to the version prior to
>>> r29223 fixes the problem for us.
>>> 
>>> We would appreciate if this change could be backed out until this
>>> problem can be resolved. I don't understand everything that's going
>>> on during nib loading well enough to  attempt to solve this myself.
>>> Thanks!
>>> 
>>> -- Doug Simons Principal Developer
>>> 
>>> 
>>> TestPlant Inc       T    +1 720-890-0211 ext 13 4730 Walnut Street  F    +1
>>> 720-890-0209 Boulder, CO 80301      doug.sim...@testplant.com USA 
>>> http://www.testplant.com This email and any attachments may contain
>>> privileged / confidential information. If you have received this
>>> email in error or believe that you are not the intended recipient,
>>> please delete all content and attached files and contact TestPlant
>>> via the switchboard on +1 720-890-0211 or via return e-mail. You
>>> should not copy, forward or use any part of the contents in any way.
>>> Any such unauthorised use or disclosure may be unlawful.
>>> 

_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev

Reply via email to