Re: Building GNUstep from source - failed tests

[Fred Kiefer]

On 12.01.2013 12:49, Richard Frith-Macdonald wrote:
> On 12 Jan 2013, at 09:23, edwin ancaer wrote:
>
> > Hello,
> >
> > I was looking for an interesting platform to refresh my programming skills. 
> > After looking around a while, it found GNUstep/Etoilé looking interesting.
> >
> > I've been building GNUstep following the instructions in 'Downloads: 
> > Installation instruction'  on the Etoilé website.
> >
> > Everything went fine I sucessfully built make, base, gui and back.
> >
> > However, when I ran the 'make check' for the base package, I got the following 
> > result:
> >
> >     7552 Passed tests
> >       25 Failed tests
> >       19 Dashed hopes
> >        5 Skipped sets
> >        1 Failed file
> >
> > Given the fact that ProjectCenter seems to be working fine, do I have to worry 
> > about this, or is it normal that some tasts fail?
>
> No, it's not normal for any tests to fail.
>
> All tests are supposed to pass on all platforms, (known platform specific 
> issues should be dealt with by skipped sets or dashed hopes).
>
> So it's good to report and try to sort out any/every test failure.

I just run the base tests on my 64bit OpenSuse machine and had a failed 
file here as well (and also a few expected failed tests from NSLocale, 
we need to mark those as hopes). The failing file in create.m in 
NSPointerArray and running it with a debugger gives this backtrace:


#0  0x00007ffff7421731 in objc_msg_lookup () from /usr/lib64/libobjc.so.4
#1  0x00007ffff78bcf18 in pointerFunctionsAssign (value=<optimized out>, 
addr=0x644960,
    PF=<optimized out>) at NSConcretePointerFunctions.h:142
#2  pointerFunctionsAssign (value=<optimized out>, addr=0x644960, 
PF=<optimized out>)
    at NSPointerArray.m:455
#3  pointerFunctionsMove (new=0x644960, PF=0x643030, old=<optimized out>)
    at NSConcretePointerFunctions.h:172
#4  -[NSConcretePointerArray insertPointer:atIndex:] (self=0x643028, 
_cmd=<optimized out>,
    pointer=0x608740 <_OBJC_INSTANCE_8>, index=0) at NSPointerArray.m:467
#5  0x00000000004056c3 in main () at create.m:33

I think that problem is when trying to move the nil value that has been 
inserted in the step before. The strange thing is that the line where 
this fails should only be used for strong pointers where the test code 
uses no options what so ever.