Re: some gnustep-base tests are randomly failing

[Fred Kiefer]

On 28.10.2011 19:03, Richard Frith-Macdonald wrote:
> On 28 Oct 2011, at 17:47, Sebastian Reitenbach wrote:
>
> > On Friday, October 28, 2011 16:57 CEST, Fred
> > Kiefer<fredkiefer@gmx.de>  wrote:
> >
> > > On 28.10.2011 16:44, Sebastian Reitenbach wrote:
> > > > I found some time, trying to play with other locales so I did:
> > > > export LC_CTYPE='en_US.UTF-8' and reran the testsuite for a
> > > > couple of times. The random tests don't seem to fail anymore.
> > > > But with the LC_CTYPE exported, some other tests fail
> > > > constantly: Testing json.m... Running
> > > > base/NSJSONSerialization/json.m. Failed test:     json.m:42 ...
> > > > Round trip worked with pretty printing Failed test:
> > > > json.m:44 ... Round trip worked with ugly printing Failed test:
> > > > json.m:45 ... Round trip worked through stream
> > >
> > > These should be fixed by Richard latest change.
> > >
> > > > Testing basic.m... Running base/NSNumberFormatter/basic.m...
> > > > Failed test:       basic.m:50 ... numeric and space padding OK
> > > > Expected '  001234' and got ' _ 01234'
> > >
> > > Interesingly, before Richards change I got the same error, but
> > > now I have different ones here:
> > >
> > > base/NSNumberFormatter/basic.m: Failed test:       basic.m:23 ...
> > > default format same as Cocoa Failed test:       basic.m:27 ...
> > > Handle leading zeroes in fractional part: 1.01 Failed test:
> > > basic.m:31 ... Handle leading zeroes in fractional part: 1.1
> > > Failed test:       basic.m:37 ... -setAllowsFloats: does not
> > > effect rounding Failed test:       basic.m:58 ... prefix and
> > > suffix used properly Failed test:       basic.m:62 ...
> > > negativeFormat used for -ve number
> > >
> > > No idea why this is the case, but I had these tests failing
> > > previously.
> >
> > With a new svn checkout, the tests I had with LC_CTYPE failing are
> > gone, and I now get the same like Fred:
> >
> >
> > Testing basic.m... Running base/NSNumberFormatter/basic.m... Start
> > set:       basic.m:7 ... basic Passed test:       basic.m:17 ...
> > +[NSNumberFormatter alloc] returns a NSNumberFormatter Failed test:
> > basic.m:23 ... default format same as Cocoa Failed test:
> > basic.m:27 ... Handle leading zeroes in fractional part: 1.01
> > Failed test:       basic.m:31 ... Handle leading zeroes in
> > fractional part: 1.1 Failed test:       basic.m:37 ...
> > -setAllowsFloats: does not effect rounding 2011-10-28 04:33:38.407
> > basic[1213] NSNumberFormatter-getObjectValue:forString:... not
> > fully implemented Passed test:       basic.m:40 ... float input is
> > disallowed 2011-10-28 04:33:38.412 basic[1213]
> > NSNumberFormatter-getObjectValue:forString:... not fully
> > implemented Passed test:       basic.m:44 ... allowsFloat error
> > Passed test:       basic.m:50 ... numeric and space padding OK
> > Failed test:       basic.m:58 ... prefix and suffix used properly
> > Failed test:       basic.m:62 ... negativeFormat used for -ve
> > number Passed test:       basic.m:65 ... notANumber special case
> > Passed test:       basic.m:69 ... format string of length 1 End
> > set:         basic.m:71 ... basic
>
> I think all this depends on the ICU library and the code Stefan
> Bidigaray added to use it recently. Perhaps he can say why a change
> of locale should make the tests fail  ... that might be
> normal/correct behavior of the API (in which case I guess we need to
> improve the tests), or it might be some simple change to the code is
> required to get the ICU code to behave consistently.

At least on my machine this isn't the case, I don't have ICU installed. 
When adding some log statements in noticed that the test code actually 
raises an exception, so I ran gdb against the test code and this 
produced the following back trace:


gdb) bt
#0  -[NSException raise] (self=0x790ad8, _cmd=0x7ffff7d36e20) at
NSException.m:955
#1  0x00007ffff7883f08 in +[NSException raise:format:]
(self=0x7ffff7d36a40,
    _cmd=<value optimized out>, name=0x7ffff7d371a0, format=0x7ffff7d087a0)
    at NSException.m:835
#2  0x00007ffff77f6895 in -[GSMutableString
replaceCharactersInRange:withString:] (
    self=0x790388, _cmd=0x7ffff7d87c60, aRange=..., aString=0x7ffff7d5d7e0)
    at GSString.m:4414
#3  0x00007ffff792a6ea in -[NSMutableString
replaceOccurrencesOfString:withString:options:range:] (self=0x790388,
_cmd=<value optimized out>, replace=0x7ffff7d5d3e0, by=0x7ffff7d5d7e0,
    opts=<value optimized out>, searchRange=...) at NSString.m:5514
#4  0x00007ffff78d0cca in -[NSNumberFormatter stringForObjectValue:]
(self=0x69c598,
    _cmd=<value optimized out>, anObject=<value optimized out>) at
NSNumberFormatter.m:1300
#5  0x000000000040685d in main () at basic.m:22


gdb) up 2
#2  0x00007ffff77f6895 in -[GSMutableString 
replaceCharactersInRange:withString:] (
    self=0x790388, _cmd=0x7ffff7d87c60, aRange=..., aString=0x7ffff7d5d7e0)
    at GSString.m:4414
4414      GS_RANGE_CHECK(aRange, _count);
(gdb) p aRange
$1 = {location = 0, length = 1}
(gdb) po self
<object returns empty description>
(gdb) p [self length]
$2 = 0