=================== BUG #6743: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=6743&group_id=99
Changes by: Richard Frith-Macdonald <[EMAIL PROTECTED]>
Date: Tue 11/25/2003 at 10:40 (GMT)
------------------ Additional Follow-up Comments ----------------------------
What I was thinking of was making the cached numbers members of some new subclass
where -dealloc had been overridden to raise an exception. So there would be no
runtime overhead on dealloc of a non-cached number.
=================== BUG #6743: FULL BUG SNAPSHOT ===================
Submitted by: moseshall Project: GNUstep
Submitted on: Tue 11/25/2003 at 03:06
Category: Base/Foundation Severity: 5 - Major
Bug Group: Bug Resolution: None
Assigned to: None Status: Open
Summary: Distinct NSNumbers with the same value dealloc each other
Original Submission: Distinct NSNumbers with the *same value* can dealloc each other.
The following code snippet crashes gnustep-base 1.7.3 possibly because of NSNumber
caching. If I don't call [n1 release] there is no crash. If this is due to caching
strategy, then it can make NSNumber very fragile when numbers are expected to persist
as long as retained.
#include <Foundation/Foundation.h>
int main (int argc, const char *argv[], const char *env[])
{
NSNumber* n1 = [NSNumber numberWithLong:1];
NSNumber* n2 = [NSNumber numberWithLong:1];
NSLog(@"%@(%d)n", n1, [n1 retainCount]);
NSLog(@"%@(%d)n", n2, [n2 retainCount]);
[n1 release]; //<--problem here
// The next line crashes. n2 has gone away!
NSLog(@"%@(%d)n", n2, [n2 retainCount]);
return 0;
}
Thanks for your attention.
Brian 'Moses' Hall
[EMAIL PROTECTED]
Follow-up Comments
*******************
-------------------------------------------------------
Date: Tue 11/25/2003 at 10:40 By: CaS
What I was thinking of was making the cached numbers members of some new subclass
where -dealloc had been overridden to raise an exception. So there would be no
runtime overhead on dealloc of a non-cached number.
-------------------------------------------------------
Date: Tue 11/25/2003 at 10:17 By: ayers
In principal I agree, but it depends on the cost. I'm not sure how much the hit would
be, but expect numbers to be created and destroyed often in GDL2 based applications.
So if each dealloc resulted in a hash look up... well, depending on the
implementation, I guess we may need to test it.
-------------------------------------------------------
Date: Tue 11/25/2003 at 08:00 By: CaS
I think raising an exception upon an attempt to deallocate a cached NSNumber would be
a nice feature.
-------------------------------------------------------
Date: Tue 11/25/2003 at 06:24 By: CaS
There is a bug in the test program ... it releases an object it does not own, so a
crash does not seem unreasonable (in the general case releasing objects you don't own
is bound to cause crashes).
Is the report a suggestion that the library should be changed to crash elsewhere, or
to have code added to watch for this case and raise an exception or something similar,
or perhaps to simply ignore the extra release and keep on going?
CC list is empty
No files currently attached
For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=6743&group_id=99
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
_______________________________________________
Bug-gnustep mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-gnustep
