Re: [Gnustep-cvs] r27706 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m
Fred Kiefer wrote: > The other change is more interesting. Did you switch of the memory > management for NIB connections because of the ugly memory problems this > is causing on applications like Bean? We have noticed this during our > session in Bergamo as well. My impression there was that outlets set via > the NIB connection mechanism get deallocated behind the back of the > application. We didn't have the time to investigate this in detail. My > first idea was the perhaps the mechanism we use to set the outlets > doesn't follow the documented memory management rules, but as far as I > can tell this wasn't the case. I think we are using GSObjCFindVariable() > and GSObjCSetVariable() and these should work correctly. Perhaps we > could switch to setValue:forKey: here to have a more general mechanism > in place. But basically this would end up calling the same code, it is > just a bit cleaner and easier to understand. > Looks like today is the day of replying to my own mails :-) I looked at that code a bit deeper and there is indeed a difference between setValue:forKey: and the current code that establish outlet connections. From there we call GSObjCSetVariable() while KVC uses GSObjCSetVal() and the later uses ASSIGN() to set instance variable which are objects. This should explain the problem we are getting with NIB loading, we are not retaining any ivars that get set directly via outlets. I am going to change the code in NSNibOutletConnector and we should then proceed to clean up the missing release calls in GSNibLoading.m. For the few places where retaining the ivar is wrong we now will need to add internal methods that set the ivar without retain. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r27706 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m
Fred, The NSDrawer change: * I think that setFrame:display:animate: didn't exist when I originally wrote the code for NSDrawer. The issue is that on Windows systems and on some slower systems the code that was there (in NSDrawer) was very slow and was causing the drawer to open very very slowly. The GSNibLoading change: * As stated in the ChangeLog, this one is temporary until I find all of the places this is crashing. The issue is not in GSNibLoading itself, but is in some of the nib loading code (initWithCoder: methods) of objects being loaded. I believe this to be the case since I have found a few places where objects were not being retained properly (GSMenuItemSeparator, as one example) that were causing crashes. I put this temporary change in place to prevent crashes for people who simply want their apps to work (yes, at the cost of a memory leak) until I can locate all of the places where this is an issue. Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Fred Kiefer To: Gregory Casamento ; GNUstep Developer Sent: Wednesday, January 28, 2009 2:43:20 AM Subject: Re: [Gnustep-cvs] r27706 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m Gregory Casamento wrote: > Author: gcasa > Date: Tue Jan 27 21:33:17 2009 > New Revision: 27706 > > URL: http://svn.gna.org/viewcvs/gnustep?rev=27706&view=rev > Log: > This is a temporary change. Commenting out RELEASE(_connections) will be > reverted ASAP. > > Modified: > libs/gui/trunk/ChangeLog > libs/gui/trunk/Source/GSNibLoading.m > libs/gui/trunk/Source/NSDrawer.m Could you please explain these two changes? I am more interested in the one for NIB loading, although the drawer change also surprised me. The old code there looks strange, why didn't we use setFrame:display:animate: in the first place. Still it looked like a working feature... The other change is more interesting. Did you switch of the memory management for NIB connections because of the ugly memory problems this is causing on applications like Bean? We have noticed this during our session in Bergamo as well. My impression there was that outlets set via the NIB connection mechanism get deallocated behind the back of the application. We didn't have the time to investigate this in detail. My first idea was the perhaps the mechanism we use to set the outlets doesn't follow the documented memory management rules, but as far as I can tell this wasn't the case. I think we are using GSObjCFindVariable() and GSObjCSetVariable() and these should work correctly. Perhaps we could switch to setValue:forKey: here to have a more general mechanism in place. But basically this would end up calling the same code, it is just a bit cleaner and easier to understand. Anybody out there with an idea, what might go wrong here? Or perhaps I am looking at the wrong bit of code. It might well be that the memory leak happens somewhere completely different. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [Gnustep-cvs] r27706 - in /libs/gui/trunk: ChangeLog Source/GSNibLoading.m Source/NSDrawer.m
Gregory Casamento wrote: > Author: gcasa > Date: Tue Jan 27 21:33:17 2009 > New Revision: 27706 > > URL: http://svn.gna.org/viewcvs/gnustep?rev=27706&view=rev > Log: > This is a temporary change. Commenting out RELEASE(_connections) will be > reverted ASAP. > > Modified: > libs/gui/trunk/ChangeLog > libs/gui/trunk/Source/GSNibLoading.m > libs/gui/trunk/Source/NSDrawer.m Could you please explain these two changes? I am more interested in the one for NIB loading, although the drawer change also surprised me. The old code there looks strange, why didn't we use setFrame:display:animate: in the first place. Still it looked like a working feature... The other change is more interesting. Did you switch of the memory management for NIB connections because of the ugly memory problems this is causing on applications like Bean? We have noticed this during our session in Bergamo as well. My impression there was that outlets set via the NIB connection mechanism get deallocated behind the back of the application. We didn't have the time to investigate this in detail. My first idea was the perhaps the mechanism we use to set the outlets doesn't follow the documented memory management rules, but as far as I can tell this wasn't the case. I think we are using GSObjCFindVariable() and GSObjCSetVariable() and these should work correctly. Perhaps we could switch to setValue:forKey: here to have a more general mechanism in place. But basically this would end up calling the same code, it is just a bit cleaner and easier to understand. Anybody out there with an idea, what might go wrong here? Or perhaps I am looking at the wrong bit of code. It might well be that the memory leak happens somewhere completely different. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev