Re: libobjc2 release?

[Richard Frith-Macdonald]

On 13 Mar 2010, at 13:48, David Chisnall wrote:

> 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).

It was meant to just go to you ... I presumed you would *want* maximum debug to 
look at a problem.

> 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:

Argh ... that's exactly it ... I forgot I had a locally hacked copy of 
gnustep-make to set the -fobjc-nonfragile-abi flag, and had replaced it with 
the latest make from svn.


> @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.

I'm not sure what 100% nonsense  means ... looks like it's doing exactly what's 
needed as I understand it ...

If we are building for use without the nonfragile abi, then we hide all the 
instance variables behind a single value '_internal' ... this is the common 
case (ie the setup almost everyone currently has).
If we are building for use *with* the nonfragile abi, then either
a. we are building the class implementation itsself, and all instance variables 
are visible or
b. we are building some code which uses the class ... and no  instance 
variables are visible

I think what was really missing was a check to ensure that we don't 
accidentally try to work without the nonfragile abi using a copy of the base 
library built to work *with* it.
I've added a bit of preprocessor stuff which (unless I made a mistake) ought to 
check that.

> 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.  

I'll have to check that ... unless you already have a better test?

> The GNUstep test suite would be a lot more helpful if it wasn't full of tests 
> that always (or commonly) fail.

It isn't.

> 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.


Here's a run:

--- Running tests in base ---

base/Functions/runtime.m:
FAIL: SubClass1 has one protocol

base/NSException/basic.m:
FAIL: raises exception in description
FAIL: working callStackSymbols
: Uncaught exception NSGenericException, reason: Terminate
FAIL: base/NSException/basic.m

base/NSLock/doubleLocking.m:
FAIL: Recursive lock with NSLock deadlocks ... this is not a real test, just a 
reminder that recursively locking should deadlock the thread after printing a 
diagnostic message
FAIL: Recursive lock with NSConditionLock deadlocks ... this is not a real 
test, just a reminder that recursively locking should deadlock the thread after 
printing a diagnostic message

base/NSObject/test02.m:
FAIL: +conformsToProtocol returns YES on a protocol implemented in a category
FAIL: -conformsToProtocol returns YES on a protocol implemented in a category

base/NSURL/basic.m:
FAIL: Can load a page from www.w3.org
FAIL: Status of load is 200 for www.w3.org
FAIL: Status of load is 404 for www.w3.org/silly-file-name

      1 
    259 COMPLETED
     11 FAIL
   5219 PASS

That's 11 failures in 5230 tests ... even if the 11 were all broken tests, it 
would seem rather irrational to not run the testsuite with a ratio of working 
test so broken of 52350:11 just because you aren't sure if the 11 are real 
failures.  It would make hugely more sense to fix any broken tests!

looking at the failures:

1, in runtime.m the count of protocols is a libobjc2 failure I already flagged 
up to you... a real issue, not a broken test.

Of the 3 in NSException, the first *is* a broken test,
the second is a real error you know about, where libc fails to return stack 
symbols,
the third is partly broken (ie the report is incomplete), but clear what's 
going on if you check it.

The two locking ones are marked as not real tests ... expected failures.

The two conformsToProtocol errors are (presumably as I don't see them 
elsewhere) libobjc2 failures

the three URL loading ones are because I don't have SSL support configured on 
that system, so it can't make the https connection out.

Given your point about the NSOperation test sometimes failing due to being 
system/scheduler dependent, there are probably quite a few tests in there which 
are not completely reliable ... partially broken but fine most of the time.  
Even so, clearly it makes far more sense to improve and add to the testsuite 
than to ignore it.