Re: libobjc2 objc_setassociatedobject issue

[David Chisnall]

I've now added a test for this to the libobjc2 test suite, but it passes and so 
does not appear to be the cause.  Your issue appears to be the dictionary being 
over-retained.  I will investigate further.

David

P.S. When sending test cases, it helps to send them in the format of a test 
suite for the thing you are testing, or as stand-alone programs.  I'd have got 
to this a lot sooner if I didn't have to hack on the test to make it compile.

On 19 Nov 2013, at 01:33, Doug Warren <address@hidden> wrote:

> Hi Guys,
> 
> Was tracking a memory leak in an existing app and tracked it down to 
> objc_setassociatedobject not working as expected from the code being 
> developed for the Apple Runtime.  The docs around objc_setassociatedobject 
> seem to imply it follows the Apple Runtime but this simple gtest will pass on 
> Apple but fail on libobjc/GNUStep Base:
> 
> static BOOL deallocCalled = NO;
> static const char* objc_setAssociatedObjectKey = 
> "objc_setAssociatedObjectKey";
> 
> @interface NSMutableDictionary(setAssociatedObjectTest)
> @end
> 
> @implementation NSMutableDictionary(setAssociatedObjectTest)
> 
> -(void) dealloc
> {
>     deallocCalled = YES;
>     [super dealloc];
> }
> 
> @end
> 
> TEST(objc_setAssociatedObject, AssociatedObjectsAreReleased)
> {
>     @autoreleasepool {
>         NSObject* object = [[NSString alloc] init];
> 
>         NSMutableDictionary *info = [NSMutableDictionary 
> dictionaryWithCapacity:1];
>         objc_setAssociatedObject(object, &objc_setAssociatedObjectKey, info, 
> OBJC_ASSOCIATION_RETAIN);
> 
>         [object release];
>     }
> 
>     ASSERT_TRUE(deallocCalled);
> }
> 
> Adding calls to GSDebugAllocationList before/after the autorelease pool:
> 1     NSDataMalloc
> 1     GSMutableDictionary
> 
> Shows that the dictionary leaks.
> 
> Any thoughts?
> _______________________________________________
> Gnustep-dev mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnustep-dev