Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
Am 19.03.2010 09:20, schrieb Fred Kiefer: My current position on NIB loading is that no magic should happen there. Objects created while loading a NIB file should follow the standard rules. Nothing will be retained except for the top level objects being retained in the top level object array. (And of course instantiated and visible windows by the normal window display mechanism) That way anything that is not retained by the owner or specifically extracted from the top level object array will be freed after loading the NIB file when no other reference exists. If we can all agree on this position (and better yet, check that it is valid on Cocoa), I am going to change our code into this direction. This may require some extra handling in NSWindowController or NSDocument. Wolfgang was right, the problem in Bean was not relate to NIB loading at all. This issue should be resolved (or at least worked around), by the change I made to NSDocument last night. The problem with NIB loading was rather that we retained too much. I tried to resolve this by adding proper releasing of the real object to many of the NIB loading helper classes and correcting the top level object handling there as well. This is only the beginning of more clean up, but should resolve most of the known issues. Could you please give this code a try and load your favourite NIB file? I haven't tried the results this change has on Gorm, which should also be tested. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
Hi Fred! Am 19.03.2010 09:20, schrieb Fred Kiefer: My current position on NIB loading is that no magic should happen there. Objects created while loading a NIB file should follow the standard rules. Nothing will be retained except for the top level objects being retained in the top level object array. (And of course instantiated and visible windows by the normal window display mechanism) That way anything that is not retained by the owner or specifically extracted from the top level object array will be freed after loading the NIB file when no other reference exists. If we can all agree on this position (and better yet, check that it is valid on Cocoa), I am going to change our code into this direction. This may require some extra handling in NSWindowController or NSDocument. Wolfgang was right, the problem in Bean was not relate to NIB loading at all. This issue should be resolved (or at least worked around), by the change I made to NSDocument last night. The problem with NIB loading was rather that we retained too much. I tried to resolve this by adding proper releasing of the real object to many of the NIB loading helper classes and correcting the top level object handling there as well. This is only the beginning of more clean up, but should resolve most of the known issues. Thanks for cleaning this up. I had a look at this, too, and was totally frustrated by the code. Apparently, the author of that code either does not understand or does not care about object ownership. Could you please give this code a try and load your favourite NIB file? I haven't tried the results this change has on Gorm, which should also be tested. Unfortunately, your change introduces a new bug. In NSBundleAdditions, the owner is now bound to key NSNibOwner, but GSGormLoading (still) expects it to be NSOwner. GSNibLoading also uses NSOwner as primary key but at least uses NSNibOwner as fallback. I also needed a patch to slightly extend the lifetime of a window controller when its window is closed (see patch below); this is similar to your change in NSDocument. Apart from that, the change works fine for me so far (though I haven't tested it much). Interestingly, the nib loading code fixes a space leak that is (still) present in the gorm loader where some views of a window are not released when the window is closed. Wolfgang NSWindowController.patch Description: Binary data ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
I'm not positive, but I'm guessing that these nib loading changes checked in
over the weekend are the cause of new crashes that we are seeing when building
with the latest code (r30018) on Windows.
Our app now crashes on launch. Here's the relevant gdb output:
Program received signal SIGSEGV, Segmentation fault.
0x67848ae6 in objc_msg_lookup () from c:\GNUstep\GNUstep\System\Tools\objc-1.dll
(gdb) bt
#0 0x67848ae6 in objc_msg_lookup () from
c:\GNUstep\GNUstep\System\Tools\objc-1.dll
#1 0x63c4ba52 in -[NSWindow dealloc] (self=0x151f1a8, _cmd=0x65b59950) at
NSWindow.m:754
#2 0x65a2afad in -[NSObject release] (self=0x151f1a8, _cmd=0x65b1b850) at
NSObject.m:1890
#3 0x6594337f in -[GSArray dealloc] (self=0x99fee40, _cmd=0x65b59950) at
GSArray.m:136
#4 0x65a2afad in -[NSObject release] (self=0x99fee40, _cmd=0x65b2dc50) at
NSObject.m:1890
#5 0x659971dc in -[NSAutoreleasePool emptyPool] (self=0x1215cb8,
_cmd=0x65b2dcc0)
at NSAutoreleasePool.m:441
#6 0x65996ff2 in -[NSAutoreleasePool dealloc] (self=0x1215cb8, _cmd=0x65b2dcb8)
at NSAutoreleasePool.m:342
#7 0x65996fb8 in -[NSAutoreleasePool release] (self=0x1215cb8, _cmd=0x53b228)
at NSAutoreleasePool.m:335
#8 0x004209de in -[EggplantApplication finishLaunching] (self=0x1211510,
_cmd=0x63cf1af0)
at EggplantApplication.m:262
#9 0x63adedfc in -[NSApplication run] (self=0x1211510, _cmd=0x63ce6ca0) at
NSApplication.m:1506
#10 0x63ac1f0f in NSApplicationMain (argc=1, argv=0x10ae698) at Functions.m:74
#11 0x00401a65 in main (argc=1, argv=0x10ae698) at main.m:13
(gdb) up
#1 0x63c4ba52 in -[NSWindow dealloc] (self=0x151f1a8, _cmd=0x65b59950) at
NSWindow.m:754
754 [NSApp removeWindowsItem: self];
(gdb) p NSApp
$1 = (class NSApplication *) 0x1211510
(gdb) p *NSApp
$2 = {{{isa = 0xfeeefeee}, _interface_style = 4277075694, _next_responder =
0xfeeefeee,
_menu = 0xfeeefeee}, _default_context = 0xfeeefeee, _current_event =
0xfeeefeee,
_session = 0xfeeefeee, _key_window = 0xfeeefeee, _main_window = 0xfeeefeee,
_delegate = 0xfeeefeee, _listener = 0xfeeefeee, _main_menu = 0xfeeefeee,
_windows_menu = 0xfeeefeee, _app_is_launched = 238 'ε', _app_is_running = 254
'■',
_app_is_active = 238 'ε', _app_is_hidden = 254 '■', _unhide_on_activation =
238 'ε',
_windows_need_update = 254 '■', _app_icon = 0xfeeefeee, _app_icon_window =
0xfeeefeee,
_hidden = 0xfeeefeee, _inactive = 0xfeeefeee, _hidden_key = 0xfeeefeee,
_infoPanel = 0xfeeefeee, _runLoopPool = 0xfeeefeee}
(gdb)
As you can see, NSApp has been freed!! I'm guessing this is because it is the
File's Owner for our main nib file? I'm not sure how else to explain it getting
released.
By adding [NSApp retain] we can get beyond this point, but are hitting other
problems with object loaded from nibs.
Can someone familiar with the recent changes see what might be causing NSApp to
be released? Something is clearly broken here. Thanks!
Doug
On Mar 22, 2010, at 8:12 AM, Wolfgang Lux wrote:
Hi Fred!
Am 19.03.2010 09:20, schrieb Fred Kiefer:
My current position on NIB loading is that no magic should happen there.
Objects created while loading a NIB file should follow the standard
rules. Nothing will be retained except for the top level objects being
retained in the top level object array. (And of course instantiated and
visible windows by the normal window display mechanism)
That way anything that is not retained by the owner or specifically
extracted from the top level object array will be freed after loading
the NIB file when no other reference exists.
If we can all agree on this position (and better yet, check that it is
valid on Cocoa), I am going to change our code into this direction.
This may require some extra handling in NSWindowController or NSDocument.
Wolfgang was right, the problem in Bean was not relate to NIB loading at
all. This issue should be resolved (or at least worked around), by the
change I made to NSDocument last night.
The problem with NIB loading was rather that we retained too much. I
tried to resolve this by adding proper releasing of the real object to
many of the NIB loading helper classes and correcting the top level
object handling there as well. This is only the beginning of more clean
up, but should resolve most of the known issues.
Thanks for cleaning this up. I had a look at this, too, and was totally
frustrated by the code. Apparently, the author of that code either does not
understand or does not care about object ownership.
Could you please give this code a try and load your favourite NIB file?
I haven't tried the results this change has on Gorm, which should also
be tested.
Unfortunately, your change introduces a new bug. In NSBundleAdditions, the
owner is now bound to key NSNibOwner, but GSGormLoading (still) expects it to
be NSOwner. GSNibLoading also uses NSOwner as primary key but at least uses
NSNibOwner as fallback.
I also needed a patch to slightly extend the lifetime of a
Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
Thank you for pointing out the problem with NSApp. This was caused by a
missing retain in some part of GSNibLoading that I hadn't cleaned up.
Hopefully this is fixed now. If there are any other issues I hope we can
resolve them as quick as that one.
Fred
Am 22.03.2010 18:24, schrieb Doug Simons:
I'm not positive, but I'm guessing that these nib loading changes
checked in over the weekend are the cause of new crashes that we are
seeing when building with the latest code (r30018) on Windows.
Our app now crashes on launch. Here's the relevant gdb output:
Program received signal SIGSEGV, Segmentation fault. 0x67848ae6 in
objc_msg_lookup () from c:\GNUstep\GNUstep\System\Tools\objc-1.dll
(gdb) bt #0 0x67848ae6 in objc_msg_lookup () from
c:\GNUstep\GNUstep\System\Tools\objc-1.dll #1 0x63c4ba52 in
-[NSWindow dealloc] (self=0x151f1a8, _cmd=0x65b59950) at
NSWindow.m:754 #2 0x65a2afad in -[NSObject release] (self=0x151f1a8,
_cmd=0x65b1b850) at NSObject.m:1890 #3 0x6594337f in -[GSArray
dealloc] (self=0x99fee40, _cmd=0x65b59950) at GSArray.m:136 #4
0x65a2afad in -[NSObject release] (self=0x99fee40, _cmd=0x65b2dc50)
at NSObject.m:1890 #5 0x659971dc in -[NSAutoreleasePool emptyPool]
(self=0x1215cb8, _cmd=0x65b2dcc0) at NSAutoreleasePool.m:441 #6
0x65996ff2 in -[NSAutoreleasePool dealloc] (self=0x1215cb8,
_cmd=0x65b2dcb8) at NSAutoreleasePool.m:342 #7 0x65996fb8 in
-[NSAutoreleasePool release] (self=0x1215cb8, _cmd=0x53b228) at
NSAutoreleasePool.m:335 #8 0x004209de in -[EggplantApplication
finishLaunching] (self=0x1211510, _cmd=0x63cf1af0) at
EggplantApplication.m:262 #9 0x63adedfc in -[NSApplication run]
(self=0x1211510, _cmd=0x63ce6ca0) at NSApplication.m:1506 #10
0x63ac1f0f in NSApplicationMain (argc=1, argv=0x10ae698) at
Functions.m:74 #11 0x00401a65 in main (argc=1, argv=0x10ae698) at
main.m:13 (gdb) up #1 0x63c4ba52 in -[NSWindow dealloc]
(self=0x151f1a8, _cmd=0x65b59950) at NSWindow.m:754 754 [NSApp
removeWindowsItem: self]; (gdb) p NSApp $1 = (class NSApplication *)
0x1211510 (gdb) p *NSApp $2 = {{{isa = 0xfeeefeee}, _interface_style
= 4277075694, _next_responder = 0xfeeefeee, _menu = 0xfeeefeee},
_default_context = 0xfeeefeee, _current_event = 0xfeeefeee, _session
= 0xfeeefeee, _key_window = 0xfeeefeee, _main_window = 0xfeeefeee,
_delegate = 0xfeeefeee, _listener = 0xfeeefeee, _main_menu =
0xfeeefeee, _windows_menu = 0xfeeefeee, _app_is_launched = 238 'ε',
_app_is_running = 254 '■', _app_is_active = 238 'ε', _app_is_hidden =
254 '■', _unhide_on_activation = 238 'ε', _windows_need_update = 254
'■', _app_icon = 0xfeeefeee, _app_icon_window = 0xfeeefeee, _hidden =
0xfeeefeee, _inactive = 0xfeeefeee, _hidden_key = 0xfeeefeee,
_infoPanel = 0xfeeefeee, _runLoopPool = 0xfeeefeee} (gdb)
As you can see, NSApp has been freed!! I'm guessing this is because
it is the File's Owner for our main nib file? I'm not sure how else
to explain it getting released.
By adding [NSApp retain] we can get beyond this point, but are
hitting other problems with object loaded from nibs.
Can someone familiar with the recent changes see what might be
causing NSApp to be released? Something is clearly broken here.
Thanks!
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
Thanks Fred,
It looks like that has fixed the problem with NSApp. It also appears to have
solved the other problem that I reported to you privately. We will do some more
testing and let you know if we run into any other problems with nib loading.
Thanks for the quick fix!
Regards,
Doug
On Mar 22, 2010, at 3:27 PM, Fred Kiefer wrote:
Thank you for pointing out the problem with NSApp. This was caused by a
missing retain in some part of GSNibLoading that I hadn't cleaned up.
Hopefully this is fixed now. If there are any other issues I hope we can
resolve them as quick as that one.
Fred
Am 22.03.2010 18:24, schrieb Doug Simons:
I'm not positive, but I'm guessing that these nib loading changes
checked in over the weekend are the cause of new crashes that we are
seeing when building with the latest code (r30018) on Windows.
Our app now crashes on launch. Here's the relevant gdb output:
Program received signal SIGSEGV, Segmentation fault. 0x67848ae6 in
objc_msg_lookup () from c:\GNUstep\GNUstep\System\Tools\objc-1.dll
(gdb) bt #0 0x67848ae6 in objc_msg_lookup () from
c:\GNUstep\GNUstep\System\Tools\objc-1.dll #1 0x63c4ba52 in
-[NSWindow dealloc] (self=0x151f1a8, _cmd=0x65b59950) at
NSWindow.m:754 #2 0x65a2afad in -[NSObject release] (self=0x151f1a8,
_cmd=0x65b1b850) at NSObject.m:1890 #3 0x6594337f in -[GSArray
dealloc] (self=0x99fee40, _cmd=0x65b59950) at GSArray.m:136 #4
0x65a2afad in -[NSObject release] (self=0x99fee40, _cmd=0x65b2dc50)
at NSObject.m:1890 #5 0x659971dc in -[NSAutoreleasePool emptyPool]
(self=0x1215cb8, _cmd=0x65b2dcc0) at NSAutoreleasePool.m:441 #6
0x65996ff2 in -[NSAutoreleasePool dealloc] (self=0x1215cb8,
_cmd=0x65b2dcb8) at NSAutoreleasePool.m:342 #7 0x65996fb8 in
-[NSAutoreleasePool release] (self=0x1215cb8, _cmd=0x53b228) at
NSAutoreleasePool.m:335 #8 0x004209de in -[EggplantApplication
finishLaunching] (self=0x1211510, _cmd=0x63cf1af0) at
EggplantApplication.m:262 #9 0x63adedfc in -[NSApplication run]
(self=0x1211510, _cmd=0x63ce6ca0) at NSApplication.m:1506 #10
0x63ac1f0f in NSApplicationMain (argc=1, argv=0x10ae698) at
Functions.m:74 #11 0x00401a65 in main (argc=1, argv=0x10ae698) at
main.m:13 (gdb) up #1 0x63c4ba52 in -[NSWindow dealloc]
(self=0x151f1a8, _cmd=0x65b59950) at NSWindow.m:754 754 [NSApp
removeWindowsItem: self]; (gdb) p NSApp $1 = (class NSApplication *)
0x1211510 (gdb) p *NSApp $2 = {{{isa = 0xfeeefeee}, _interface_style
= 4277075694, _next_responder = 0xfeeefeee, _menu = 0xfeeefeee},
_default_context = 0xfeeefeee, _current_event = 0xfeeefeee, _session
= 0xfeeefeee, _key_window = 0xfeeefeee, _main_window = 0xfeeefeee,
_delegate = 0xfeeefeee, _listener = 0xfeeefeee, _main_menu =
0xfeeefeee, _windows_menu = 0xfeeefeee, _app_is_launched = 238 'ε',
_app_is_running = 254 '■', _app_is_active = 238 'ε', _app_is_hidden =
254 '■', _unhide_on_activation = 238 'ε', _windows_need_update = 254
'■', _app_icon = 0xfeeefeee, _app_icon_window = 0xfeeefeee, _hidden =
0xfeeefeee, _inactive = 0xfeeefeee, _hidden_key = 0xfeeefeee,
_infoPanel = 0xfeeefeee, _runLoopPool = 0xfeeefeee} (gdb)
As you can see, NSApp has been freed!! I'm guessing this is because
it is the File's Owner for our main nib file? I'm not sure how else
to explain it getting released.
By adding [NSApp retain] we can get beyond this point, but are
hitting other problems with object loaded from nibs.
Can someone familiar with the recent changes see what might be
causing NSApp to be released? Something is clearly broken here.
Thanks!
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
Great that you could work around the issue. It still remains to be solved in a general way. It surely helps to know how your problem was triggered. Did your controller retain the objects from the second NIB file? And then when the controller was released these objects also disappeared? My current position on NIB loading is that no magic should happen there. Objects created while loading a NIB file should follow the standard rules. Nothing will be retained except for the top level objects being retained in the top level object array. (And of course instantiated and visible windows by the normal window display mechanism) That way anything that is not retained by the owner or specifically extracted from the top level object array will be freed after loading the NIB file when no other reference exists. If we can all agree on this position (and better yet, check that it is valid on Cocoa), I am going to change our code into this direction. This may require some extra handling in NSWindowController or NSDocument. Fred Am 18.03.2010 22:49, schrieb Doug Simons: 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! ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
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 IncT+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. On Mar 13, 2010, at 6:21 AM, Fred Kiefer wrote: Am 13.03.2010 00:31, schrieb Wolfgang Lux: Fred Kiefer wrote: Thank you for looking into this. Looks like the basic difference between Cocoa and us is in the window, window controller and document interaction. And you are the sole expert we have on this :-) At the end of the day it looks like my expertise isn't needed here. The problem rather seems to be a space leak in the nib loading code, which seems to retain the owner of the nib file. To make testing a bit simpler I've attached a hopefully faithful translation of Ink's Document.gorm into a nib file with Apple's InterfaceBuilder. When I use that nib file instead of Document.gorm, Ink does not release the document when its window is closed. The window itself and its window controller are released correctly. Thank you for looking into this: I will try to resolve this issue. I remember scattering FIXME's in the NIB loading code some time ago. One of them might come in helpful now. I think it is now save to replace the NIB outlet connector code. I just checked the old code against the new runtime functions of base and as far as I can tell the old code would still work. We could just revert my change. Please do so. Done :-) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
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
Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
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. On Mar 13, 2010, at 6:21 AM, Fred Kiefer wrote: Am 13.03.2010 00:31, schrieb Wolfgang Lux: Fred Kiefer wrote: Thank you for looking into this. Looks like the basic difference between Cocoa and us is in the window, window controller and document interaction. And you are the sole expert we have on this :-) At the end of the day it looks like my expertise isn't needed here. The problem rather seems to be a space leak in the nib loading code, which seems to retain the owner of the nib file. To make testing a bit simpler I've attached a hopefully faithful translation of Ink's Document.gorm into a nib file with Apple's InterfaceBuilder. When I use that nib file instead of Document.gorm, Ink does not release the document when its window is closed. The window itself and its window controller are released correctly. Thank you for looking into this: I will try to resolve this issue. I remember scattering FIXME's in the NIB loading code some time ago. One of them might come in helpful now. I think it is now save to replace the NIB outlet connector code. I just checked the old code against the new runtime functions of base and as far as I can tell the old code would still work. We could just revert my change. Please do so. Done :-) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
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 80301doug.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. On Mar 13, 2010, at 6:21 AM, Fred Kiefer wrote: Am 13.03.2010 00:31, schrieb Wolfgang Lux: Fred Kiefer wrote: Thank you for looking into this. Looks like the basic difference between Cocoa and us is in the window, window controller and document interaction. And you are the sole expert we have on this :-) At the end of the day it looks like my expertise isn't needed here. The problem rather seems to be a space leak in the nib loading code, which seems to retain the owner of the nib file. To make testing a bit simpler I've attached a hopefully faithful translation of Ink's Document.gorm into a nib file with Apple's InterfaceBuilder. When I use that nib file instead of Document.gorm, Ink does not release the document when its window is closed. The window itself and its window controller are released correctly. Thank you for looking into this: I will try to resolve this issue. I remember scattering FIXME's in the NIB loading code some time ago. One of them might come in helpful now. I think it is now save to replace the NIB outlet connector code. I just checked the old code against the new runtime functions of base and as far as I can tell the old code would still work. We could just revert my change. Please do so. Done :-) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
Am 13.03.2010 00:31, schrieb Wolfgang Lux: Fred Kiefer wrote: Thank you for looking into this. Looks like the basic difference between Cocoa and us is in the window, window controller and document interaction. And you are the sole expert we have on this :-) At the end of the day it looks like my expertise isn't needed here. The problem rather seems to be a space leak in the nib loading code, which seems to retain the owner of the nib file. To make testing a bit simpler I've attached a hopefully faithful translation of Ink's Document.gorm into a nib file with Apple's InterfaceBuilder. When I use that nib file instead of Document.gorm, Ink does not release the document when its window is closed. The window itself and its window controller are released correctly. Thank you for looking into this: I will try to resolve this issue. I remember scattering FIXME's in the NIB loading code some time ago. One of them might come in helpful now. I think it is now save to replace the NIB outlet connector code. I just checked the old code against the new runtime functions of base and as far as I can tell the old code would still work. We could just revert my change. Please do so. Done :-) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
Am 11.03.2010 19:46, schrieb Wolfgang Lux: Fred Kiefer wrote: Am 03.03.2010 10:06, schrieb Wolfgang Lux: Fred Kiefer wrote: I am not that sure about this. When I changed to the current code it was to get the Beans application working with GNUstep. There we had the case the components loaded via NIB where released to early by GNUstep. We rather should make sure we handle all cases as similar as Apple as possible. Richard already added a simple test for KVC to see, if our behaviour there matches Cocoa. We will need a similar check for the NSNibOutletConnector. If we want to be as compatible with Apple as possible, it seems that the best way to proceed would be to restore the old code. I ran a quick test this morning, and it seems that Cocoa is calling a -setXxx: method if present. However, it does ignore private -_setXxx: methods, which KVC seems to use, though only for backward compatibility. Furthermore, Cocoa insists on the attribute name being xxx and, unlike KVC, does not assign nib components to a attribute named _xxx. So, if we want to be as compatible with Apple as possible, it seems that the best way to proceed would be to restore the old code. Or maybe to move the whole code to gnustep-base and export it from there as a GNUstep extension. Looks like you are right. I still didn't find the time to test it myself on an Apple machine. What puzzles me is why we had that issue with Bean while it seems to work well on Cocoa... I had a quick look into this. After reverting the code in -establishConnection I observe a crash in Bean under GNUstep when closing a document window. This crash happens in MyDocument -updateInspectorController:, which attempts to access views of the nib after the window has been closed and released. Apparently, the views are not (and should not be) valid at this time. From the data gathered by Apple's ObjectAlloc, it seems that this code does not crash under Cocoa because Apple manages to deallocate the objects involved in a different order. In particular, when the last window of a document is closed the document is released and deallocated *before* the last window controller and its window are released and deallocated. I'll try to have a closer look at this when I find a bit more time. Thank you for looking into this. Looks like the basic difference between Cocoa and us is in the window, window controller and document interaction. And you are the sole expert we have on this :-) I think it is now save to replace the NIB outlet connector code. I just checked the old code against the new runtime functions of base and as far as I can tell the old code would still work. We could just revert my change. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
Fred Kiefer wrote: Thank you for looking into this. Looks like the basic difference between Cocoa and us is in the window, window controller and document interaction. And you are the sole expert we have on this :-) At the end of the day it looks like my expertise isn't needed here. The problem rather seems to be a space leak in the nib loading code, which seems to retain the owner of the nib file. To make testing a bit simpler I've attached a hopefully faithful translation of Ink's Document.gorm into a nib file with Apple's InterfaceBuilder. When I use that nib file instead of Document.gorm, Ink does not release the document when its window is closed. The window itself and its window controller are released correctly. I think it is now save to replace the NIB outlet connector code. I just checked the old code against the new runtime functions of base and as far as I can tell the old code would still work. We could just revert my change. Please do so. Wolfgang Document.nib.tar Description: Unix tar archive ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
Fred Kiefer wrote: Am 03.03.2010 10:06, schrieb Wolfgang Lux: Fred Kiefer wrote: I am not that sure about this. When I changed to the current code it was to get the Beans application working with GNUstep. There we had the case the components loaded via NIB where released to early by GNUstep. We rather should make sure we handle all cases as similar as Apple as possible. Richard already added a simple test for KVC to see, if our behaviour there matches Cocoa. We will need a similar check for the NSNibOutletConnector. If we want to be as compatible with Apple as possible, it seems that the best way to proceed would be to restore the old code. I ran a quick test this morning, and it seems that Cocoa is calling a -setXxx: method if present. However, it does ignore private -_setXxx: methods, which KVC seems to use, though only for backward compatibility. Furthermore, Cocoa insists on the attribute name being xxx and, unlike KVC, does not assign nib components to a attribute named _xxx. So, if we want to be as compatible with Apple as possible, it seems that the best way to proceed would be to restore the old code. Or maybe to move the whole code to gnustep-base and export it from there as a GNUstep extension. Looks like you are right. I still didn't find the time to test it myself on an Apple machine. What puzzles me is why we had that issue with Bean while it seems to work well on Cocoa... I had a quick look into this. After reverting the code in - establishConnection I observe a crash in Bean under GNUstep when closing a document window. This crash happens in MyDocument - updateInspectorController:, which attempts to access views of the nib after the window has been closed and released. Apparently, the views are not (and should not be) valid at this time. From the data gathered by Apple's ObjectAlloc, it seems that this code does not crash under Cocoa because Apple manages to deallocate the objects involved in a different order. In particular, when the last window of a document is closed the document is released and deallocated *before* the last window controller and its window are released and deallocated. I'll try to have a closer look at this when I find a bit more time. Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
Am 03.03.2010 10:06, schrieb Wolfgang Lux: Fred Kiefer wrote: I am not that sure about this. When I changed to the current code it was to get the Beans application working with GNUstep. There we had the case the components loaded via NIB where released to early by GNUstep. We rather should make sure we handle all cases as similar as Apple as possible. Richard already added a simple test for KVC to see, if our behaviour there matches Cocoa. We will need a similar check for the NSNibOutletConnector. If we want to be as compatible with Apple as possible, it seems that the best way to proceed would be to restore the old code. I ran a quick test this morning, and it seems that Cocoa is calling a -setXxx: method if present. However, it does ignore private -_setXxx: methods, which KVC seems to use, though only for backward compatibility. Furthermore, Cocoa insists on the attribute name being xxx and, unlike KVC, does not assign nib components to a attribute named _xxx. So, if we want to be as compatible with Apple as possible, it seems that the best way to proceed would be to restore the old code. Or maybe to move the whole code to gnustep-base and export it from there as a GNUstep extension. Looks like you are right. I still didn't find the time to test it myself on an Apple machine. What puzzles me is why we had that issue with Bean while it seems to work well on Cocoa... ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
Am 02.03.2010 09:24, schrieb Wolfgang Lux:
Author: fredkiefer
Date: Sun Feb 8 13:54:21 2009
New Revision: 27812
URL: http://svn.gna.org/viewcvs/gnustep?rev=27812view=rev
Log:
Use KVC call setValue:forKey: to establish the outlet connection.
This will result in ivars being properly retained.
Modified:
libs/gui/trunk/ChangeLog
libs/gui/trunk/Source/NSBundleAdditions.m
it's been a while since you've committed this change, but I just got
round yesterday evening to track down a major space leak to exactly this
change: Windows (and apparently other entities) loaded from a nib file
never get released and deallocated. As an example, try this with Ink:
- Open the memory panel from the info panel.
- Open a new document window.
- Update the memory panel. The panel now shows one (new) NSWindow, one
(new) Document, etc.
- Close the document window.
- Update the memory panel. The Document and NSWindowController instance
are gone, the NSWindow is still alive.
If you revert your change, the NSWindow and its views are properly
released.
At first, I was assuming that your change is correct and the nib loading
code was improperly retaining the top-level entities. However, the
longer I think about it the more I am convinced that it is your change
that is wrong. In fact we do *not* want to retain ivars in general. It
is well documented by Apple that only ivars that reference top-level
entities of a nib are owned by the receiver (and this is already handled
properly by the nib loading code), other ivars are not owned. An example
for this is the tv attribute of Ink's Document objects. This attribute
must not be retained when the connection is instantiated. Otherwise, the
text view would not be released even when the window were released and
deallocated when its document is closed. [1]
Wolfgang
[1] You can trivially test this without reverting your change by adding
the statement [[aController window] autorelease] to the Document
-windowControllerDidLoadNib: method. Now the window is deallocated when
it is closed, but its text view still remains alive.
Thank you for looking into this change. My main problem with it is that
it is already a year ago that I made it, so my memory is getting week on
this.
As far as I remember this change was about replacing the usage of
GNUstep base private functions with a proper official interface. Looking
at the diff this seems to be the case. Instead of having
NSString *selName;
SEL sel;
selName = [NSString stringWithFormat: @s...@%@:,
[[_tag substringToIndex: 1] uppercaseString],
[_tag substringFromIndex: 1]];
sel = NSSelectorFromString(selName);
if (sel [_src respondsToSelector: sel])
{
[_src performSelector: sel withObject: _dst];
}
else
{
const char *nam = [_tag cString];
const char *type;
unsigned int size;
int offset;
/*
* Use the GNUstep additional function to set the instance
* variable directly.
* FIXME - need some way to do this for libFoundation and
* Foundation based systems.
*/
if (GSObjCFindVariable(_src, nam, type, size, offset))
{
GSObjCSetVariable(_src, offset, size, (void*)_dst);
}
}
we now have
[_src setValue: _dst forKey: _tag];
Even the old code was calling setter methods instead of setting an ivar
directly so retains could happen there as well. The main difference is
in the case where we have an object ivar and there is no accessor
method. There the old code would just set the ivar to the value and the
new code now does a retain in GSObjCSetVal().
I see this as a general problem of KVC, as long as GNUstep doesn't
supports ways to tell the compiler which ivars need to be retained when
setting their value, we need another mechanism to get this correct. The
only thing I can think of at the moment is to add a setter method for
these cases that wont use ASSIGN.
I also found some discussion on the dev mailing list triggered by change
r27706. I already recommended the same solution at that time, but never
implemented it myself :-(
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: r27812 - in /libs/gui/trunk: ChangeLog Source/NSBundleAdditions.m
Hi!
I remember having stumbled over this piece of code being the source of
a memory management issue of mine. Basically I renamed my setter
methods so the 'GSObjCSetVariable' branch would get used, all my
problems disappeared that way. I will dig out my project which had this
issue in the evening.
But wouldn't the proper way be to set the variables using
'GSObjCSetVariable' only?
Just my 2 cents...
Cheers,
TOM
Zitat von Fred Kiefer fredkie...@gmx.de:
Am 02.03.2010 09:24, schrieb Wolfgang Lux:
Author: fredkiefer
Date: Sun Feb 8 13:54:21 2009
New Revision: 27812
URL: http://svn.gna.org/viewcvs/gnustep?rev=27812view=rev
Log:
Use KVC call setValue:forKey: to establish the outlet connection.
This will result in ivars being properly retained.
Modified:
libs/gui/trunk/ChangeLog
libs/gui/trunk/Source/NSBundleAdditions.m
it's been a while since you've committed this change, but I just got
round yesterday evening to track down a major space leak to exactly this
change: Windows (and apparently other entities) loaded from a nib file
never get released and deallocated. As an example, try this with Ink:
- Open the memory panel from the info panel.
- Open a new document window.
- Update the memory panel. The panel now shows one (new) NSWindow, one
(new) Document, etc.
- Close the document window.
- Update the memory panel. The Document and NSWindowController instance
are gone, the NSWindow is still alive.
If you revert your change, the NSWindow and its views are properly
released.
At first, I was assuming that your change is correct and the nib loading
code was improperly retaining the top-level entities. However, the
longer I think about it the more I am convinced that it is your change
that is wrong. In fact we do *not* want to retain ivars in general. It
is well documented by Apple that only ivars that reference top-level
entities of a nib are owned by the receiver (and this is already handled
properly by the nib loading code), other ivars are not owned. An example
for this is the tv attribute of Ink's Document objects. This attribute
must not be retained when the connection is instantiated. Otherwise, the
text view would not be released even when the window were released and
deallocated when its document is closed. [1]
Wolfgang
[1] You can trivially test this without reverting your change by adding
the statement [[aController window] autorelease] to the Document
-windowControllerDidLoadNib: method. Now the window is deallocated when
it is closed, but its text view still remains alive.
Thank you for looking into this change. My main problem with it is that
it is already a year ago that I made it, so my memory is getting week on
this.
As far as I remember this change was about replacing the usage of
GNUstep base private functions with a proper official interface. Looking
at the diff this seems to be the case. Instead of having
NSString *selName;
SEL sel;
selName = [NSString stringWithFormat: @s...@%@:,
[[_tag substringToIndex: 1] uppercaseString],
[_tag substringFromIndex: 1]];
sel = NSSelectorFromString(selName);
if (sel [_src respondsToSelector: sel])
{
[_src performSelector: sel withObject: _dst];
}
else
{
const char *nam = [_tag cString];
const char *type;
unsigned int size;
int offset;
/*
* Use the GNUstep additional function to set the instance
* variable directly.
* FIXME - need some way to do this for libFoundation and
* Foundation based systems.
*/
if (GSObjCFindVariable(_src, nam, type, size, offset))
{
GSObjCSetVariable(_src, offset, size, (void*)_dst);
}
}
we now have
[_src setValue: _dst forKey: _tag];
Even the old code was calling setter methods instead of setting an ivar
directly so retains could happen there as well. The main difference is
in the case where we have an object ivar and there is no accessor
method. There the old code would just set the ivar to the value and the
new code now does a retain in GSObjCSetVal().
I see this as a general problem of KVC, as long as GNUstep doesn't
supports ways to tell the compiler which ivars need to be retained when
setting their value, we need another mechanism to get this correct. The
only thing I can think of at the moment is to add a setter method for
these cases that wont use ASSIGN.
I also found some discussion on the dev mailing list triggered by change
r27706. I already recommended the same solution at that time, but never
implemented it myself :-(
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
