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
