Re: Base status

[Fred Kiefer]

On 15.08.2011 13:51, David Chisnall wrote:
> On 15 Aug 2011, at 12:03, Fred Kiefer wrote:
>
> > Most likely this is a timing issue, does this work on other
> > machines?
>
> I don't get a failure on this one, but I think there is a problem
> with the run loops somewhere.  I get an intermittent failure on one
> of the tests.
>
> It would be worth at some point making sure all of the tests compile
> without warnings.  I spent over an hour tracking down a bug where
> the return value from NSTempDirectory() was an invalid object.  It
> turned out that there was some premature optimisation going on and
> the test was just including a small subset of the Foundation headers,
> not the main Foundation.h, so it was using an implicit declaration
> of NSTempDirectory() (another C89 bug - in C99 the compiler would
> have just rejected it because implicit declarations are no longer
> allowed) with a return type of int, so the object pointer was
> truncated to 32 bits and the test crashed when the runtime tried to
> dereference it.

I already removed most of the warnings from the tests. And I didn't get 
a warning here, looks like the includes worked out differently for you 
and me. No idea why. But removing warnings is (almost) always good practise.

> The NSURL tests actually do pass for me, but they seem to pause for
> several minutes.  Is this expected?  I thought they were broken, so
> I was killing the test program after a couple of minutes, but when I
> left the machine running tests while I went to shower I found that
> they were actually passing eventually.

I don't get this pause for NSURL, but this is on Linux, the server code 
here may be better suited for Linux than it is for FreeBSD.

> Results from FreeBSD 9 / x86-64, with the pure non-fragile ABI,
> clang, and libobjc2 trunk:
>
> 6500 Passed tests 6 Dashed hopes
>
> The dashed hopes are:
>
> > Dashed hope:     basic.m:53 ... working callStackSymbols ... if
> > this has failed it is probably due to a lack of support for
> > objective-c method names (local symbols) in the
> > backtrace_symbols() function of your libc. If so, you might lobby
> > your operating system provider for a fix.
>
>
> This one is a bug in configure.  In config.h, I HAVE_BACKTRACE is
> commented out.  HAVE_EXECINFO_H is set to 1, and HAVE_EXECINFO_H
> ought to imply HAVE_BACKTRACE.

Not sure about this one. You may well have the execinfo.h header file, 
but for some reason the linking of backtrace() fails. You should check 
in config.log for the error.

On my system backtrace and execinfo get detected, but it cannot find 
__builtin_extract_return_address.


> > Dashed hope:     test02.m:284 ... foo->bar relative symlink not
> > expanded by stringByResolvingSymlinksInPath
>
>
> Last time I looked at this one, the test was confusing and seemed to
> be testing the wrong thing anyway.

I think this test is correct, the Apple implementation of this method
explicitly states that it wont resolve symbolic links for relative path.
And the GNUstep implementation differs from that.