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=27706view=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
Fast enumeration
Since we're likely to get a compiler that knows about fast enumeration soon, I thought I'd start implementing the library support it needs. This patch defines the protocol and implements it for NSEnumerator. The collection classes will each need this implementing too. I'll do this in subsequent patches if no one else does. David fastenumeration.diff Description: Binary data ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Fast enumeration
On 28 Jan 2009, at 11:45, David Chisnall wrote: Since we're likely to get a compiler that knows about fast enumeration soon, I thought I'd start implementing the library support it needs. This patch defines the protocol and implements it for NSEnumerator. The collection classes will each need this implementing too. I'll do this in subsequent patches if no one else does. Thanks ... I added that. I had to fixing indentation/whitespace use to match GNUstep coding standards though, and remove the spurious change to NSProcessInfo.m which was also in the patch. Could you please review your local copy of NSProcessInfo.m ... Your patch contains an additional line saying '#include sys/ sysctl.h' which looks like it should not be needed as a few lines below we have the same include inside an '#ifdef HAVE_SYS_SYSCTL_H' Did you need to add the include explicitly? If so, can you figure out why the test for the header in configure.ac failed on your machine? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Fast enumeration
On 28 Jan 2009, at 12:08, Richard Frith-Macdonald wrote: and remove the spurious change to NSProcessInfo.m which was also in the patch. Ah, I forgot that was in there. It's not entirely spurious - GNUStep- base doesn't build on FreeBSD without it. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Fast enumeration
On 28 Jan 2009, at 12:08, Richard Frith-Macdonald wrote: Your patch contains an additional line saying '#include sys/ sysctl.h' which looks like it should not be needed as a few lines below we have the same include inside an '#ifdef HAVE_SYS_SYSCTL_H' Did you need to add the include explicitly? If so, can you figure out why the test for the header in configure.ac failed on your machine? On closer inspection, this has been fixed in GNUstep trunk and it now builds happily without the patch. I think I sent this to the list a while ago and didn't remove my quick hack when it was merged. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Fast enumeration
On 28 Jan 2009, at 12:16, David Chisnall wrote: On 28 Jan 2009, at 12:08, Richard Frith-Macdonald wrote: and remove the spurious change to NSProcessInfo.m which was also in the patch. Ah, I forgot that was in there. It's not entirely spurious - GNUStep-base doesn't build on FreeBSD without it. So why not? It's not present on all systems, so we can't include it unconditionally, but we *do* include it if configure was able to find it. So what breakage of configure on FreeBSD causes it to not be found? It would be good to have that fixed. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
More fast enumeration
This patch fixes a bug in the last one (I forgot to set the items pointer) and adds enumeration support to GSArray and GSMutableArray. GSArray just returns a pointer to its contents directly. GSMutableArray has a _version ivar added. This is incremented every time the collection is mutated. This allows the caller to check if the collection has changed between invocations and throw an exception if it has (this is done by calling objc_collectionMutation() which is not yet implemented on the GNU runtime). David fastenumeration2.diff Description: Binary data ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: More fast enumeration
On 28 Jan 2009, at 13:13, David Chisnall wrote: This patch fixes a bug in the last one (I forgot to set the items pointer) and adds enumeration support to GSArray and GSMutableArray. GSArray just returns a pointer to its contents directly. GSMutableArray has a _version ivar added. This is incremented every time the collection is mutated. This allows the caller to check if the collection has changed between invocations and throw an exception if it has (this is done by calling objc_collectionMutation() which is not yet implemented on the GNU runtime). Thanks ... I added that patch to svn ___ 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 fredkie...@gmx.de To: Gregory Casamento greg_casame...@yahoo.com; GNUstep Developer gnustep-dev@gnu.org 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=27706view=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
plmerge crash in latest trunk
Since my last svn update I got errors complaining that an NSZone-
related symbol was missing (what is the reason for this? Breaking the
ABI is not considered friendly.). As a result I've had to recompile
everything. This wouldn't be a major problem, except that plmerge
keeps crashing.
This is a back trace from the last core it dumped:
#0 0x28449105 in objc_msg_lookup (receiver=0xa5a5a5a5, op=0x283b0aa0)
at sendmsg.c:226
#1 0x280fac8d in GSIMapBucketForKey (map=0x28ae979c, key=
{addr = 2779096485, obj = 0xa5a5a5a5, nso = 0xa5a5a5a5}) at
GSIMap.h:341
#2 0x280faef9 in GSIMapNodeForKey (map=0x28ae979c, key=
{addr = 2779096485, obj = 0xa5a5a5a5, nso = 0xa5a5a5a5}) at
GSIMap.h:579
#3 0x280fb701 in -[GSDictionary objectForKey:] (self=0x28ae9798,
_cmd=0x28410e48,
aKey=0xa5a5a5a5) at GSDictionary.m:344
#4 0x28274dbb in -[NSUserDefaults objectForKey:] (self=0x28a29828,
_cmd=0x284110a8,
defaultName=0x28410390) at NSUserDefaults.m:1020
#5 0x2827483a in -[NSUserDefaults arrayForKey:] (self=0x28a29828,
_cmd=0x28410e00,
defaultName=0x28410390) at NSUserDefaults.m:937
#6 0x28271763 in updateCache (self=0x28a29828) at NSUserDefaults.m:109
#7 0x28272f0d in +[NSUserDefaults standardUserDefaults]
(self=0x28410dc0, _cmd=0x283d0e18)
at NSUserDefaults.m:632
#8 0x2819ab46 in -[NSDictionary writeToFile:atomically:]
(self=0x28a297f8, _cmd=0x804aab8,
path=0x28aa7268, useAuxiliaryFile=1 '\001') at NSDictionary.m:984
#9 0x0804945c in main () at plmerge.m:139
Any thoughts?
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: plmerge crash in latest trunk
Hey,
- Original Message -
From: David Chisnall csda...@swansea.ac.uk
To: Developer GNUstep gnustep-dev@gnu.org
Sent: Wednesday, January 28, 2009 10:33 PM
Subject: plmerge crash in latest trunk
Since my last svn update I got errors complaining that an NSZone-
related symbol was missing (what is the reason for this? Breaking the
ABI is not considered friendly.). As a result I've had to recompile
everything. This wouldn't be a major problem, except that plmerge
keeps crashing.
I just compiled whole base on GNU/Hurd. back doesn't terminate compilation
because plmerge segfaults. I wouldn't wonder on Hurd... but considering you
have the problem too...
I run defaults read through the debugger, sicne it crashes too on me and
the stacktrace is very similar to yours: bucket for key and nodeforkey;;;
just different parameters.
This is a back trace from the last core it dumped:
#0 0x28449105 in objc_msg_lookup (receiver=0xa5a5a5a5, op=0x283b0aa0)
at sendmsg.c:226
#1 0x280fac8d in GSIMapBucketForKey (map=0x28ae979c, key=
{addr = 2779096485, obj = 0xa5a5a5a5, nso = 0xa5a5a5a5}) at
GSIMap.h:341
#2 0x280faef9 in GSIMapNodeForKey (map=0x28ae979c, key=
{addr = 2779096485, obj = 0xa5a5a5a5, nso = 0xa5a5a5a5}) at
GSIMap.h:579
unfortunately I have no more clues than you. I run the nsarray test in
base/testing. It fails for me after printing out method insertObject:
[NSMutableArray class] atIndex: 2]. It crashes hars in user main with
objc_msg_lookup
Riccardo
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: plmerge crash in latest trunk
David Chisnall wrote:
Since my last svn update I got errors complaining that an NSZone-related
symbol was missing (what is the reason for this? Breaking the ABI is
not considered friendly.). As a result I've had to recompile
everything. This wouldn't be a major problem, except that plmerge keeps
crashing.
This is a back trace from the last core it dumped:
#0 0x28449105 in objc_msg_lookup (receiver=0xa5a5a5a5, op=0x283b0aa0)
at sendmsg.c:226
#1 0x280fac8d in GSIMapBucketForKey (map=0x28ae979c, key=
{addr = 2779096485, obj = 0xa5a5a5a5, nso = 0xa5a5a5a5}) at
GSIMap.h:341
#2 0x280faef9 in GSIMapNodeForKey (map=0x28ae979c, key=
{addr = 2779096485, obj = 0xa5a5a5a5, nso = 0xa5a5a5a5}) at
GSIMap.h:579
#3 0x280fb701 in -[GSDictionary objectForKey:] (self=0x28ae9798,
_cmd=0x28410e48,
aKey=0xa5a5a5a5) at GSDictionary.m:344
The value for aKey here looks suspicious. It isn't very like that this
number ends up as a valid pointer. (Odd numbers rarely do)
I would say the the enumerator gives back an invalid return value.
Didn't you just submit some patches for NSEnumerator? Perhaps this
problem is related.
#4 0x28274dbb in -[NSUserDefaults objectForKey:] (self=0x28a29828,
_cmd=0x284110a8,
defaultName=0x28410390) at NSUserDefaults.m:1020
#5 0x2827483a in -[NSUserDefaults arrayForKey:] (self=0x28a29828,
_cmd=0x28410e00,
defaultName=0x28410390) at NSUserDefaults.m:937
#6 0x28271763 in updateCache (self=0x28a29828) at NSUserDefaults.m:109
#7 0x28272f0d in +[NSUserDefaults standardUserDefaults]
(self=0x28410dc0, _cmd=0x283d0e18)
at NSUserDefaults.m:632
#8 0x2819ab46 in -[NSDictionary writeToFile:atomically:]
(self=0x28a297f8, _cmd=0x804aab8,
path=0x28aa7268, useAuxiliaryFile=1 '\001') at NSDictionary.m:984
#9 0x0804945c in main () at plmerge.m:139
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: plmerge crash in latest trunk
On 28 Jan 2009, at 21:33, David Chisnall wrote:
Since my last svn update I got errors complaining that an NSZone-
related symbol was missing (what is the reason for this? Breaking
the ABI is not considered friendly.). As a result I've had to
recompile everything. This wouldn't be a major problem, except that
plmerge keeps crashing.
This is a back trace from the last core it dumped:
#0 0x28449105 in objc_msg_lookup (receiver=0xa5a5a5a5,
op=0x283b0aa0) at sendmsg.c:226
#1 0x280fac8d in GSIMapBucketForKey (map=0x28ae979c, key=
{addr = 2779096485, obj = 0xa5a5a5a5, nso = 0xa5a5a5a5}) at
GSIMap.h:341
#2 0x280faef9 in GSIMapNodeForKey (map=0x28ae979c, key=
{addr = 2779096485, obj = 0xa5a5a5a5, nso = 0xa5a5a5a5}) at
GSIMap.h:579
#3 0x280fb701 in -[GSDictionary objectForKey:] (self=0x28ae9798,
_cmd=0x28410e48,
aKey=0xa5a5a5a5) at GSDictionary.m:344
#4 0x28274dbb in -[NSUserDefaults objectForKey:] (self=0x28a29828,
_cmd=0x284110a8,
defaultName=0x28410390) at NSUserDefaults.m:1020
#5 0x2827483a in -[NSUserDefaults arrayForKey:] (self=0x28a29828,
_cmd=0x28410e00,
defaultName=0x28410390) at NSUserDefaults.m:937
#6 0x28271763 in updateCache (self=0x28a29828) at NSUserDefaults.m:
109
#7 0x28272f0d in +[NSUserDefaults standardUserDefaults]
(self=0x28410dc0, _cmd=0x283d0e18)
at NSUserDefaults.m:632
#8 0x2819ab46 in -[NSDictionary writeToFile:atomically:]
(self=0x28a297f8, _cmd=0x804aab8,
path=0x28aa7268, useAuxiliaryFile=1 '\001') at NSDictionary.m:984
#9 0x0804945c in main () at plmerge.m:139
Any thoughts?
Bug introduced by your last patch ... it was copying memory in the
wrong direction on array insertion.
I missed noticing it when I reviewed your code ... guess I was
careless because I thought the code was all fast enumerations stuff
and would not break any existing code.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
