As a hopeful final follow-up to this. I opened a bug
https://savannah.gnu.org/bugs/index.php?4 with a GNUstep style failing
test that I verified fails on 1.24.6 on Ubuntu along with the fix I
mentioned above. Hopefully it'll be integrated or someone else will be
inspired by a failing test to fix it.
On Tue, Dec 17, 2013 at 2:12 AM, David Chisnall wrote:
> The new version still looks more complex than the equivalent (correct)
> code in libobjc2.
>
> David
>
> On 16 Dec 2013, at 23:49, Doug Warren wrote:
>
> > Looks like it was this optimization:
> > /* C++ destructors must be called in the opposite order to their
> >* creators, so start at the leaf class and then go up the tree until
> we
> >* get to the root class. As a small optimisation, we don't bother
> >* visiting any classes that don't have an implementation of this
> method
> >* (including one inherited from a superclass).
> >*
> >* Care must be taken not to call inherited .cxx_destruct methods.
> >*/
> > while (class_respondsToSelector(destructorClass, cxx_destruct))
> > {
> > IMP newDestructor;
> >
> > newDestructor
> > = class_getMethodImplementation(destructorClass, cxx_destruct);
> > destructorClass = class_getSuperclass(destructorClass);
> >
> > if (newDestructor != destructor)
> > {
> > newDestructor(self, cxx_destruct);
> > destructor = newDestructor;
> > }
> > }
> >
> > I replaced it with:
> > while (destructorClass)
> > {
> > if (class_respondsToSelector(destructorClass,
> cxx_destruct))
> > {
> > IMP newDestructor =
> class_getMethodImplementation(destructorClass, cxx_destruct);
> > destructorClass =
> class_getSuperclass(destructorClass);
> >
> > if (newDestructor != destructor)
> > {
> > newDestructor(self, cxx_destruct);
> > destructor = newDestructor;
> > }
> > }
> > else
> > {
> > destructorClass =
> class_getSuperclass(destructorClass);
> > }
> > }
> >
> > And it works for my test cases though I haven't checked if there was a
> performance penalty or not.
> >
> >
> > On Mon, Dec 16, 2013 at 11:30 AM, David Chisnall
> wrote:
> > This sounds like a bug in GNUstep base's object deallocation then. If
> .cxx_dealloc isn't called then ObjC++ won't work correctly either.
> >
> > David
> >
> > On 16 Dec 2013, at 19:24, Doug Warren wrote:
> >
> > > Followup to this,
> > >
> > > cleanupReferenceList() is never being called, I see the hidden class
> created and the .cxx_destruct registered but it isn't invoked. The problem
> is that I don't see how object_dispose() get's called. In the libobjc2
> Test it's called in dealloc which would explain why the libobjc2 Test
> works, but I don't see it invoked in gnustep-base anywhere. Or for that
> matter anywhere in anyone's trunk other than libobjc2's Test.h and
> RuntimeTest.m.
> > >
> > >
> > > On Fri, Dec 13, 2013 at 1:30 PM, Doug Warren
> wrote:
> > > Works without objc_setAssociatedObject:
> > > E/Z2GameLog(14278): STDOUT: [--] 1 test from
> objc_setAssociatedObject
> > > E/Z2GameLog(14278): STDOUT: [ RUN ]
> objc_setAssociatedObject.AssociatedObjectsAreReleased
> > > E/Z2GameLog(14278): STDOUT: [ OK ]
> objc_setAssociatedObject.AssociatedObjectsAreReleased (1 ms)
> > > E/Z2GameLog(14278): STDOUT: [--] 1 test from
> objc_setAssociatedObject (1 ms total)
> > >
> > > Code change:
> > > @autoreleasepool {
> > > associatedObjectTestAllocatedObject* object =
> [associatedObjectTestAllocatedObject new];
> > >
> > > associatedObjectTestAssociatedObject *info =
> [[associatedObjectTestAssociatedObject new] autorelease];
> > > // silence -Wunused-variable
> > > [info description];
> > > //objc_setAssociatedObject(object,
> &objc_setAssociatedObjectKey, info, OBJC_ASSOCIATION_RETAIN);
> > >
> > > [object release];
> > > }
> > >
> > > The reason why I had suggested that was your original post that
> NSString wouldn't be an appropriate target, got me thinking that perhaps
> there was an optimization at some point made in the runtime to NSObject
> that would similarly cause it to not work.
> > >
> > >
> > > On Fri, Dec 13, 2013 at 11:43 AM, David Chisnall
> wrote:
> > > This test case looks like it should pass irrespective of whether the
> runtime does the right thing. Since you're using
> associatedObjectTestAssociatedObject for both objects, deallocating the
> original autoreleased one ought to set associatedObjectDeallocCalled. Can
> you confirm whether this test fails for you on GNUstep with the
> objc_setAssociatedObject() call removed?
> > >
> > > David
> > >
> > > On 13 Dec 2013, at 18:27, Doug Warren wrote:
>
