[bugs #6743] Distinct NSNumbers with the same value dealloc each other

[Richard Frith-Macdonald]

This mail is an automated notification from the bugs tracker
 of the project: GNUstep.

/**************************************************************************/
[bugs #6743] Latest Modifications:

Changes by: 
                Richard Frith-Macdonald <rfm@gnu.org>
'Date: 
                Sun 11/30/03 at 09:08 (GMT)

            What     | Removed                   | Added
---------------------------------------------------------------------------
              Status | Open                      | Closed


------------------ Additional Follow-up Comments ----------------------------
Code in cvs modified to raise an exception if a cached small number is 
deallocated ... more user friendly than crashing on attempting to reference a 
deallocated object where user code has released a number it doesn't own.






/**************************************************************************/
[bugs #6743] Full Item Snapshot:

URL: <http://savannah.gnu.org/bugs/?func=detailitem&item_id=6743>
Project: GNUstep
Submitted by: Moses Hall
On: Tue 11/25/03 at 03:06

Category:  Base/Foundation
Severity:  5 - Average
Item Group:  Bug
Resolution:  None
Assigned to:  None
Status:  Closed


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

moses@blugs.com

Follow-up Comments
------------------


-------------------------------------------------------
Date: Sun 11/30/03 at 09:08         By: CaS
Code in cvs modified to raise an exception if a cached small number is 
deallocated ... more user friendly than crashing on attempting to reference a 
deallocated object where user code has released a number it doesn't own.

-------------------------------------------------------
Date: Tue 11/25/03 at 22:36         By: moseshall
Aside from my assertion that this is counterintuitive, my face is burning with 
shame. Thanks for the pointer.

-------------------------------------------------------
Date: Tue 11/25/03 at 21: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/03 at 21: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/03 at 11:09         By: ayers
Yes, that would be very good.

-------------------------------------------------------
Date: Tue 11/25/03 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/03 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/03 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/03 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?














For detailed info, follow this link:
<http://savannah.gnu.org/bugs/?func=detailitem&item_id=6743>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/