=================== BUG #6743: LATEST MODIFICATIONS ================== http://savannah.gnu.org/bugs/?func=detailbug&bug_id=6743&group_id=99
Changes by: Alexander Malmberg <[EMAIL PROTECTED]> Date: Tue 11/25/2003 at 22:52 (Europe/Stockholm) ------------------ Additional Follow-up Comments ---------------------------- [NSNumber +numberWithLong:] returns an autoreleased object, not an object you own. You might want to read http://www.stepwise.com/Articles/Technical/HoldMe.html . =================== BUG #6743: FULL BUG SNAPSHOT =================== Submitted by: moseshall Project: GNUstep Submitted on: Tue 11/25/2003 at 04: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 22:52 By: alexm [NSNumber +numberWithLong:] returns an autoreleased object, not an object you own. You might want to read http://www.stepwise.com/Articles/Technical/HoldMe.html . ------------------------------------------------------- Date: Tue 11/25/2003 at 22:38 By: moseshall I confess I don't understand how the test program fails to own the numbers n1 and n2, because it allocated them. I think given "principle of least surprise" I expect these entities to be independent of each other, just as if they were created using malloc() or if they were some other NSObject subclass. Doing otherwise breaks retain/release balance. I would suggest ignoring a request to dealloc a cached NSNumber if the program must keep track of how many identical NSNumbers it has created (essentially duplicating the cache). (Insert newbie disclaimer here.) I would be curious to know how Cocoa handles the test program. ------------------------------------------------------- Date: Tue 11/25/2003 at 12:09 By: ayers Yes, that would be very good. ------------------------------------------------------- Date: Tue 11/25/2003 at 11: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 11: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 09: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 07: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
