Re: libobjc2 release?

[David Chisnall]

On 13 Mar 2010, at 07:42, Richard Frith-Macdonald wrote:

> 
> On 13 Mar 2010, at 07:35, Richard Frith-Macdonald wrote:
> 
>> 
>> On 11 Mar 2010, at 12:57, David Chisnall wrote:
>> 
>>> Hi Everyone,
>>> 
>>> Clang has now had the release branch created, and I'd like to do a libobjc2 
>>> release to coincide with their release.  Please can everyone test clang + 
>>> libobjc2.  We can still fix bugs in either before the release, but they 
>>> need to be reported.
>> 
>> When I run the NSOperation 'threads.m' test from the testsuite, it crashes 
>> with this warning:
>> 
>> Instance variables in OpFlag overlap superclass NSOperationOffset of first 
>> instance variable, thread, is 8Last instance variable in superclass, 
>> dependencies, ends at offset 36This probably means that you are subclassing 
>> a class from a library, which has changed in a binary-incompatible way.
>> 
>> I attach the full log (source code is in the current svn repository).

It's difficult to read your logs - you seem to have ignored the instructions in 
libobjc2 and compiled it in debug mode, so your terminal gets spammed with 
thousands of irrelevant lines hiding the ones that I actually care about (not 
to mention resulting in your sending almost 1MB of this to everyone on the 
mailing list).

I can't reproduce your problem at the moment.  If I just compile the test with 
the nonfragile ABI, it works fine.  Compiling -base seems to be broken for me; 
GSFormat.m generates invalid asm (I think this is a problem that's fixed in 
LLVM, I haven't updated for a week or so).  

Looking at the code, however, this error is exactly what I would expect to 
appear if you had compiled -base with the non-fragile ABI but the test with the 
fragile ABI:

@interface NSOperation : NSObject
{
#if>GS_NONFRAGILE
#  if>--defined(GS_NSOperation_IVARS)
@public GS_NSOperation_IVARS
#  endif
#else
@private id _internal;
#endif
}

This is 100% nonsense.  For compatibility with both ABIs, please copy what I 
did in NSCache.h.  Looking at that file, it appears that you have subsequently 
changed the code there to make it break when you subclass NSCache and compile 
with GCC or clang with the fragile ABI too.

When using the fragile ABI, you MUST be able to see the same ivars that the 
superclass uses.  The non-fragile ABI is not magic.  You can subclass fragile 
ABI classes with non-fragile ABI ones without knowing their ivar layout, but 
when you subclass a non-fragile class with a fragile one the superclass is 
treated as fragile.  

Your conditional stuff here will break every single fragile-ABI application 
when you compile -base with the non-fragile ABI.  The check in libobjc2 is 
doing exactly the right thing - it is telling you that your code is nonsense 
and that running it would result in random heap corruption and that it prefers 
to abort instead of breaking randomly.  



Unrelated, but the test here is very unreliable as it depends on the CPU load 
and scheduler interaction.  It works correctly for me around 50% of the time, 
but the "thread exit occurs after five seconds" test fails at other times.  

The GNUstep test suite would be a lot more helpful if it wasn't full of tests 
that always (or commonly) fail.  Marking these as expected failures would, at 
least, make tracking regressions easier.  I rarely bother running it, because I 
never know which of the 20+ failures are potentially the result of something 
that I've done, and which are just broken tests.

> Hmm ... I sent you that because I'd known about it for a few days and hadn't 
> got round to looking at it.
> 
> But I just started a full run of the testsuite, and current svn is failing 
> really early on in the base/Functions/runtime.m test (and I'm pretty sure 
> this used to work).


No, this never worked.  It's fixed now.

David

-- Sent from my IBM 1620