Re: Base tests errors

[Richard Frith-Macdonald]

> On 19 Mar 2016, at 10:35, Bertrand Gmail <bertrand.dekoninck@gmail.com> wrote:
> 
> Hi, I've got failed tests with the latest base. I'm on debian 8 x86, with 
> clang, and my Locale LANG and LC_NUMERIC settings are fr_FR.utf8.
> 
> First with NSLocale :
> 
> "--- Running tests in base/NSLocale ---
> 
> base/NSLoc--- Running tests in base/NSLocale ---
> 
> base/NSLocale/general.m:
> Failed test:       general.m:60 ... NSLocaleGroupingSeparator key returns '.' 
> "
> 
> I've got this in Tests.log :
> " Failed test:       general.m:60 ... NSLocaleGroupingSeparator key returns 
> '.'
> Expected '.' and got ' '(unicode codepoint 160) ".
> 
> 
> Second failed test : the usual NSNumberFormatter one :
> 
> "--- Running tests in base/NSNumberFormatter ---
> 
> base/NSNumberFormatter/basic10_4.m:
> Failed test:         basic10_4.m:149 ... negativeFormat used for -ve number"
> 
> I've got this log in Tests.log :
> "Failed test:         basic10_4.m:149 ... negativeFormat used for -ve number
> Expected '(R$1.235)' and got '_R$1.235'".

Thanks ... I don't really understand what's causing the above ... as far as I 
can see in these testcases we are checking bnehavior of a specific locale (so 
what your default locale is set to should not matter).
Perhaps the specific version of the ICU package on your system is having an 
effect on the values returned.
On the other hand the codepoint 160 is a non-breaking-space, which may be the 
grouping separator in your default french locales; but we are using a spanish 
locale at this point.  I think to see what's happening you'd probably need to 
run under gdb and set a breakpoint just before getting the grouping separator, 
then step therough the code to see what locale is really being used (and what 
string the ICU library is returning).

> And the third with NSUrl :
> 
> --- Running tests in base/NSURL ---
> 
> base/NSURL/test00.m:
> Failed test:     test00.m:51 ... NSURL chunked test OK
> 
> I've got this in Tests.log :
> "Testing test00.m...
> Running base/NSURL/test00.m...
> 2016-03-19 10:55:13.401 test00[21046:21046] Unable to connect to 
> 127.0.0.1:1234 via socket ... Connect attempt failed - Connection refused
> Failed test:     test00.m:51 ... NSURL chunked test OK".

In this case I'\m fairly sure we have a race condition ... the test spawns a 
subprocess to act as a web server, waits for half a second, and then tries to 
send a request to it.  The 'Connection refused' response suggests that the 
subprocess has not yet started up.  We should probably modify the testcases by 
adding a mechanism to check:
a. that the subprocess is ready before we send a request
b. that the subprocess has not terminated
rather than just relying on a short delay.
If this is the problem, then re-running the test is likely to result in a pass.