I saw the test that you checked in to svn and modified my code to match it:
static BOOL associatedObjectDeallocCalled = NO; static const char* objc_setAssociatedObjectKey = "objc_setAssociatedObjectKey"; @interface associatedObjectTestAssociatedObject : NSObject @end @implementation associatedObjectTestAssociatedObject -(void) dealloc { associatedObjectDeallocCalled = YES; [super dealloc]; } @end @interface associatedObjectTestAllocatedObject : NSObject @end @implementation associatedObjectTestAllocatedObject @end TEST(objc_setAssociatedObject, AssociatedObjectsAreReleased) { #if !Z2_APPLE GSDebugAllocationActive(YES); GSDebugAllocationList(YES); #endif @autoreleasepool { associatedObjectTestAllocatedObject* object = [associatedObjectTestAllocatedObject new]; associatedObjectTestAssociatedObject *info = [[associatedObjectTestAssociatedObject new] autorelease]; objc_setAssociatedObject(object, &objc_setAssociatedObjectKey, info, OBJC_ASSOCIATION_RETAIN); [object release]; } #if !Z2_APPLE EXPECT_STREQ(GSDebugAllocationList(YES), "1\tNSDataMalloc\n"); #endif ASSERT_TRUE(associatedObjectDeallocCalled); } On the Apple runtime it passes still: [----------] 1 test from objc_setAssociatedObject [ RUN ] objc_setAssociatedObject.AssociatedObjectsAreReleased [ OK ] objc_setAssociatedObject.AssociatedObjectsAreReleased (0 ms) [----------] 1 test from objc_setAssociatedObject (0 ms total) On Gnustep/objc2: E/Z2GameLog(12157): STDOUT: [----------] 1 test from objc_setAssociatedObject E/Z2GameLog(12157): STDOUT: [ RUN ] objc_setAssociatedObject.AssociatedObjectsAreReleased E/Z2GameLog(12157): STDOUT: /data/testnations.git/jujulib/Tests/objc-utility/objc_setAssociatedObjectTest.h:44: Failure E/Z2GameLog(12157): STDOUT: Value of: "1\tNSDataMalloc\n" E/Z2GameLog(12157): STDOUT: Actual: "1 NSDataMalloc E/Z2GameLog(12157): STDOUT: " E/Z2GameLog(12157): STDOUT: Expected: GSDebugAllocationList(((BOOL)1)) E/Z2GameLog(12157): STDOUT: Which is: "1 NSDataMalloc E/Z2GameLog(12157): STDOUT: 1 associatedObjectTestAssociatedObject E/Z2GameLog(12157): STDOUT: " E/Z2GameLog(12157): STDOUT: /data/testnations.git/jujulib/Tests/objc-utility/objc_setAssociatedObjectTest.h:47: Failure E/Z2GameLog(12157): STDOUT: Value of: innerObjectDeallocCalled E/Z2GameLog(12157): STDOUT: Actual: false E/Z2GameLog(12157): STDOUT: Expected: true E/Z2GameLog(12157): STDOUT: [ FAILED ] objc_setAssociatedObject.AssociatedObjectsAreReleased (1 ms) E/Z2GameLog(12157): STDOUT: [----------] 1 test from objc_setAssociatedObject (2 ms total) My runtime environment unfortunately isn't in a position to run the libobjc tests directly. Do you have any suggestions as to what I should be looking for? Perhaps there's something in the GNUStep Foundation NSObject that's causing it to fail but works with the libobjc Test object? On Fri, Dec 13, 2013 at 9:01 AM, Doug Warren <doug.war...@gmail.com> wrote: > Thanks David, > > I'll investigate more on our end. I actually had changed that from > NSString to NSObject just to be sure that it wasn't related to that. (Why > in the above stupid example it was cast to NSObject though Alloced as > NSString, I had intended it to just be a double dummy NSObject.) The actual > case where we ran into this was more complex and I feel there's still an > issue but I'll go back and confirm it. > > I was looking at another issue that we had with NSAutoreleasePool and > trying to isolate it to a test case. If I get that I'll construct it as a > standalone program as well. > > > On Fri, Dec 13, 2013 at 6:44 AM, David Chisnall < > david.chisn...@cl.cam.ac.uk> wrote: > >> Ah, sorry, I was reading your example the other way around. This seems >> to be because [[NSString alloc] init] returns a singleton on GNUstep. I >> don't think this is necessarily a bug, as there's nothing in the contract >> for NSString that says that it needs to return a new instance for different >> immutable strings. >> >> In general, using associated objects on immutable objects is a bad idea, >> because it breaks the assumption that you can use equal instances >> interchangeably. >> >> David >> >> On 13 Dec 2013, at 14:03, David Chisnall <david.chisn...@cl.cam.ac.uk> >> wrote: >> >> > 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 <doug.war...@gmail.com> 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 >> >> Gnustep-dev@gnu.org >> >> https://lists.gnu.org/mailman/listinfo/gnustep-dev >> > >> > >> > _______________________________________________ >> > Gnustep-dev mailing list >> > Gnustep-dev@gnu.org >> > https://lists.gnu.org/mailman/listinfo/gnustep-dev >> >> >
_______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev