[P5P] [perl #121079] lib/locale.t: new failures on Darwin/PPC

I have some ideas about what could be happening, but I really need a
debugger on a Darwin machine to see for sure. Until one shows up, could
you rerun the test with the environment variable PERL_DEBUG_FULL_TEST=2
set, and send me the results?

FWIW I can't reproduce these new problems on my Darwin PPC system, but
it's osvers=9.8.0, not osvers=8.11.0 like Jim's. This with

% git describe
v5.19.8-107-ge0580a6

Attached.

---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=121079

As of commit 59100ba95cd44a06c460d63e262e2d291b35e721, no improvement.

# The following locales^M
#^M
# eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8^M
# lt_LT.ISO8859-13 lt_LT.ISO8859-4^M
#^M
# had problems.^M


---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=121079

Karl,

Have you had a chance to take a look at this?

Given the age of this platform, *fixing* the problem would be nice but *understanding* the cause of the breakage is probably more important.

Thank you very much.
Jim Keenan

---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=121079

I'm going to need the output of a run with the environment variable set
properly. I don't know what you were doing, but you haven't
successfully set it. If you are doing it on a separate line, in Linux,
it needs to be exported. A single line command on Linux would be

PERL_DEBUG_FULL_TEST=2 ./perl -Ilib -T lib/locale.t > locale.log 2>&1

I presume the same thing works on Darwin, but don't know for sure

On second thought, also add a -DL option to the command line

PERL_DEBUG_FULL_TEST=2 ./perl -Ilib -T -DL lib/locale.t > locale.log 2>&1

I never got an email that you had responded, but I looked at the ticket
after you said something in irc, and found the output I needed. What's
happening is that the three eu_ES locales are saying that the decimal
radix character is the apostrophe, which I find hard to believe. I
found a version of that locale on the internet which has a comma as the
decimal point.

I can write a short C program to send you to compile and run to verify
that Perl is not getting mixed up about this, but I suspect Perl is
right about it.

That would mean that Perl is making some assumptions that the decimal
point is never going to be a quoting character. I am thinking that it's
not worth trying to fix that. Craig was unable to reproduce your issue
with a later version of the OS. Though it may be that he just doesn't
have those locales installed. But I think it is likely that
the locale on your OS version is buggy, and it should have been fixed in
later versions.

I have a friend living in Basque Spain who uses Apple stuff. I could
see if he knows anything about this.

Thanks for your investigation. Please send me (on or off list) that C
program and any instructions. Once we identify the problem, we can
always put SKIP blocks in the test file for this platform/version.

Thank you very much.
Jim Keenan

I have them:

% uname -v
Darwin Kernel Version 9.8.0: Wed Jul 15 16:57:01 PDT 2009;
root:xnu-1228.15.4~1/RELEASE_PPC
% locale -a | grep eu_ES
eu_ES
eu_ES.ISO8859-1
eu_ES.ISO8859-15
eu_ES.UTF-8

I sent Jim a C program to print the radix characters. It showed for these locales
that the radix was a string of two characters: An apostrophe followed by a space. Since Craig isn't having this problem on his later version of libc, this appears to be a bug in these locales that has since been fixed. I was wrong when I told Jim offlist that a single-byte locale, such as 8859, can only have a single byte radix character. In fact the radix is a string, so this is legal POSIX . I *think* also that Perl can cope with a multi-char radix, but it can't cope with this one. From the error messages, it is likely that Perl can't handle a quote character being part of a decimal point. As I said above, I don't believe it's worth fixing this, given until and if we are ever presented with a legitimate locale that has this characteristic.

The reason this hasn't shown up before is the same reason the Lithuanian locales used to pass. I have added a lot of locale tests in 5.19 that never were there before. In this case, it started failing when I added some new radix tests. (In the Lithuanian case, tests for upper/lowercase pairs showed that the ENG character casing hasn't been implemented correctly).

locale.t has also been updated so that if a certain percentage of tests on a machine pass completely, the failures don't fail the test as a whole. For most platforms the number is >5% failure triggers the whole test failing. The percentage can be varied depending on platform. For MSWindows, every locale but the C locale has at least one violation of the POSIX standard, so the acceptable percentage of failures is 99.9%.

Rather than make special cases for these tests, I think the general mechanism is good enough. If it's the case that these failures are pushing the failure rate too high for this platform and OS version, then we can up the acceptable failure rate enough to get it to pass.

Karl, thank you for the time and effort you have put into this investigation.

Let me see if I understand the situation correctly. The problem I reported had two parts.

First, 5 unit tests in lib/locale.t that had been passing for many years suddenly started to fail. With the recent renumbering of the tests, those tests are now:

#####
not ok 295 Verify that a different locale radix works when doing "==" with a constant
not ok 296 Verify that a different locale radix works when doing "==" with a scalar
...
not ok 300 Verify that "==" with a scalar and an intervening sprintf still works in inner no locale
...
not ok 303 Verify that after a no-locale block, a different locale radix still works when doing "==" with a scalar and an intervening sprintf
...
not ok 305 Verify that don't get warning under "==" even if radix is not a dot
#####

Second, the number of failing locales on this platform increased from 2 to 6:

#####
eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8
lt_LT.ISO8859-13 lt_LT.ISO8859-4
#####

The 4 eu_* locales are new failures; the 2 lt_* locales are problematic even on more recent versions of Darwin.

The FAIL which I am getting in lib/locale.t on Darwin/PPC is caused by the 5 'not ok' tests, i.e., the first problem. The FAIL is not, per se, caused by the increased number of problematic locales.

The overall FAIL in lib/locale.t is causing 'make test' as a whole to FAIL on this platform. Hence, to get 'make test' to PASS, we need to address the 5 failing unit tests. In other contexts (t/io/eintr.t) we have tested for platform and OS version and simply SKIPped tests known to fail on a certain platform. Would that be acceptable here?

Thank you very much.
Jim Keenan

---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=121079

I had misunderstood this problem, but it turns out that the offending
commit had to be b6d186bba098ec33d9f80ce56b932da1ad7a069c,
which removed the following comments and code:

<
   < if ($^O eq 'darwin') {
   < # Darwin 8/Mac OS X 10.4 and 10.5 have bad Basque locales: perl bug

    #35895,
   < # Apple bug ID# 4139653. It also has a problem in Byelorussian.
   < (my $v) = $Config{osvers} =~ /^(\d+)/;
   < if ($v >= 8 and $v < 10) {
   < debug "# Skipping eu_ES, be_BY locales -- buggy in Darwin\n";
   < @Locale = grep ! m/^(eu_ES(?:\..*)?|be_BY\.CP1131)$/, @Locale;
   < } elsif ($v < 12) {
   < debug "# Skipping be_BY locales -- buggy in Darwin\n";
   < @Locale = grep ! m/^be_BY\.CP1131$/, @Locale;
   < }
   < }


So, the reason this didn't fail until after this commit was these
locales were skipped. I had thought when I made that commit that
the new scheme of allowing a percentage of failures would cover these,
but there are complications, which I need to look into the best way to
fix this.

On 2/24/14 1:09 AM, karl williamson via RT wrote:
[snip]
My manual bisecting last night confirms this.

803505a9dec91bbcf4dc2400c1400d3c80f8848c PASS (with the 2 failing lt_*
locales)

b6d186bba098ec33d9f80ce56b932da1ad7a069c FAIL (with 5 individual tests
failing and eu_ES eu_ES.ISO8859-1 eu_ES.ISO8859-15 eu_ES.UTF-8
additional locale failures).

Would it be possible to revert b6d186bba098ec33d9f80ce56b932da1ad7a069c
until a better solution is found?

Thank you very much.
Jim Keenan

It's best to not skip testing an entire locale because it is defective in one area. I had forgotten that the way locale.t works is that some test failures are considered likely to be a core failure, and some tests are considered to likely be a bad locale definition, and only are considered a core failure if more than an acceptable percentage of locales fail. These failures were in the first group, but really should be in the second.

Attached are two patches that move these tests to the second group. Please apply them to make sure that your machine passes with them. Then I will push them to blead.

I tested on my machine by creating a temporary hack to locale.c that returns the bad radix string for the Basque locales. With that, I was able to reproduce your problem. With these patches, the .t passes for me.

On Mon Feb 24 11:23:02 2014, khw wrote:
[snip]
The two patches DWIMmed. On darwin/ppc, lib/locale.t once again PASSes because the 5 tests that were failing are now marked TODO. The 4 es_* locales are still listed as having problems -- as are the 2 lt_* locales -- but that is not causing the test file as a whole to fail. Consequently, for the first time in four weeks, 'make test' is once again PASSing on this platform.

I also tested the patches on linux/x86_64 and darwin/x86_64. lib/locale.t was not failing on those platforms. The two patches do no harm.

So, please apply the patches to blead and then close this RT.

Thank you very much.
Jim Keenan

---
via perlbug: queue: perl5 status: open
https://rt.perl.org/Ticket/Display.html?id=121079

The commit that actually fixed this was
b057411ddb1a3d8b6ab062d667c8e39f80cd7343