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 <[email protected]> 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 > [email protected] > https://lists.gnu.org/mailman/listinfo/gnustep-dev _______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
