[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Base tests errors
From: |
Richard Frith-Macdonald |
Subject: |
Re: Base tests errors |
Date: |
Sun, 20 Mar 2016 11:52:21 +0000 |
> 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.
- Base tests errors, Bertrand Gmail, 2016/03/19
- Re: Base tests errors,
Richard Frith-Macdonald <=