lib/locale.t: new failures on Darwin/PPC #13554
Comments
From @jkeenanI last successfully built and tested Perl on Darwin/PPC on Jan 19 2014 Tonight I was testing a smoke-me branch I created to test alh's patch. ##### In addition, more locales had problems. Previously, I would get these ##### But this evening I got: ##### I have been compiling blead on this machine weekly for two years. This While I haven't bisected, suspicion naturally falls on the Thank you very much. |
From @jkeenanok 1 verify that isn't tainted: not tainted outside 'use locale' Test Summary Report ../lib/locale.t (Wstat: 0 Tests: 495 Failed: 5) |
From @jkeenanSummary of my perl5 (revision 5 version 19 subversion 9) configuration: Characteristics of this binary (from libperl): |
From @khwilliamsonOn 01/24/2014 08:09 PM, James E Keenan (via RT) wrote:
I have some ideas about what could be happening, but I really need a |
|
The RT System itself - Status changed from 'new' to 'open' |
From @craigberryOn Sat, Jan 25, 2014 at 11:26 AM, Karl Williamson
FWIW I can't reproduce these new problems on my Darwin PPC system, but % git describe |
From @jkeenanOn Sat Jan 25 09:27:02 2014, public@khwilliamson.com wrote:
Attached. |
From @jkeenanok 1 verify that isn't tainted: not tainted outside 'use locale' # Argument "1'23" isn't numeric in numeric eq (==) at lib/locale.t line 1419. # Argument "1'23" isn't numeric in numeric eq (==) at lib/locale.t line 1417. # Argument "1'23" isn't numeric in numeric eq (==) at lib/locale.t line 1419. # Argument "1'23" isn't numeric in numeric eq (==) at lib/locale.t line 1417. # Argument "1'23" isn't numeric in numeric eq (==) at lib/locale.t line 1419. # Argument "1'23" isn't numeric in numeric eq (==) at lib/locale.t line 1470. # Argument "1'23" isn't numeric in numeric eq (==) at lib/locale.t line 1472. # 99.5% of locales pass the following test, so it is likely that the failures [�[01;31mperl�[00m] �[01;33m505 �[00m$ �[K Script done on Sat Jan 25 15:50:39 2014 |
From @jkeenanOn Thu Jan 30 05:04:35 2014, jkeenan wrote:
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. |
From @khwilliamsonOn 02/09/2014 11:19 AM, James E Keenan via RT wrote:
I'm going to need the output of a run with the environment variable set 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 |
From @jkeenanOn Sun Feb 09 20:13:07 2014, public@khwilliamson.com wrote:
Please let me know if the attached works for you. Thank you very much. |
From @khwilliamsonOn 02/09/2014 09:12 PM, Karl Williamson wrote:
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 |
From @jkeenanOn Mon Feb 10 12:41:19 2014, public@khwilliamson.com wrote:
Please see new attachment. |
From @khwilliamsonOn 02/10/2014 01:40 PM, Karl Williamson wrote:
I never got an email that you had responded, but I looked at the ticket I can write a short C program to send you to compile and run to verify That would mean that Perl is making some assumptions that the decimal I have a friend living in Basque Spain who uses Apple stuff. I could |
From @jkeenanOn 2/19/14 1:15 AM, Karl Williamson wrote:
Thanks for your investigation. Please send me (on or off list) that C Thank you very much. |
From @craigberryOn Wed, Feb 19, 2014 at 12:15 AM, Karl Williamson
I have them: % uname -v |
From @khwilliamsonI 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. |
From @jkeenanOn Sat Feb 22 21:27:22 2014, khw wrote:
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: ##### Second, the number of failing locales on this platform increased from 2 to 6: ##### 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. |
From @khwilliamsonOn 02/23/2014 06:50 AM, James E Keenan via RT wrote:
I had misunderstood this problem, but it turns out that the offending < #35895, So, the reason this didn't fail until after this commit was these |
From @jkeenanOn 2/24/14 1:09 AM, karl williamson via RT wrote:
My manual bisecting last night confirms this. 803505a PASS (with the 2 failing lt_* b6d186b FAIL (with 5 individual tests Would it be possible to revert b6d186b Thank you very much. |
From @khwilliamsonOn Mon Feb 24 03:40:31 2014, jkeen@verizon.net wrote:
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. |
From @khwilliamson0002-lib-locale.t-Change-an-array-to-a-hash.patchFrom 16348e8f95730e05d8ff0a873e623c6ee025ed7a Mon Sep 17 00:00:00 2001
From: Karl Williamson <public@khwilliamson.com>
Date: Mon, 24 Feb 2014 11:56:47 -0700
Subject: [PATCH 2/3] lib/locale.t: Change an array to a hash
This is more naturally a hash in that it is a list of numbers, not
necessarily consecutive, and each time through the loop the same number
was getting pushed, so had multiple entries for each by the time it was
finished.
---
lib/locale.t | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/lib/locale.t b/lib/locale.t
index 42dde69..ae92eec 100644
--- a/lib/locale.t
+++ b/lib/locale.t
@@ -41,7 +41,7 @@ my $acceptable_fold_failure_percentage = ($^O =~ / ^ ( MSWin32 | AIX ) $ /ix)
: 5;
# The list of test numbers of the problematic tests.
-my @problematical_tests;
+my %problematical_tests;
use Dumpvalue;
@@ -1342,7 +1342,7 @@ foreach my $Locale (@Locale) {
report_multi_result($Locale, $locales_test_number, \@f);
foreach ($first_casing_test_number..$locales_test_number) {
- push @problematical_tests, $_;
+ $problematical_tests{$_} = 1;
}
@@ -1841,7 +1841,7 @@ foreach my $Locale (@Locale) {
}
}
report_multi_result($Locale, $locales_test_number, \@f);
- push @problematical_tests, $locales_test_number;
+ $problematical_tests{$locales_test_number} = 1;
}
# [perl #109318]
@@ -1894,7 +1894,7 @@ foreach $test_num ($first_locales_test_number..$final_locales_test_number) {
print "# It usually indicates a problem in the environment,\n";
print "# not in Perl itself.\n";
}
- if ($Okay{$test_num} && grep { $_ == $test_num } @problematical_tests) {
+ if ($Okay{$test_num} && grep { $_ == $test_num } keys %problematical_tests) {
no warnings 'experimental::autoderef';
# Round to nearest .1%
my $percent_fail = (int(.5 + (1000 * scalar(keys $Problem{$test_num})
--
1.8.3.2
|
From @khwilliamson0003-lib-locale.t-Make-more-tests-not-fail-unless-is-bad-.patchFrom 51389049800b3c7a4c2cfc2d7a98ffd5fa10e3e6 Mon Sep 17 00:00:00 2001
From: Karl Williamson <public@khwilliamson.com>
Date: Mon, 24 Feb 2014 12:00:03 -0700
Subject: [PATCH 3/3] lib/locale.t: Make more tests not fail unless is bad for
enough locales
locale.t has some tests that fail even one locale fails; and it has some
tests where failure doesn't happen unless a sufficient percentage of
locales have the same problem.
The first set should be for tests whose failure indicates a basic
problem in locale handling; and the second set should be for tests where
it could be that just a locale definition is bad.
Prior to this patch, tests dealing with radix problems were considered
in the first category, but in fact it's possible that just the locale
definition for the radix is wrong. This is what happened for some older
Darwin versions for their Basque locales, which caused locale.t to show
failures, whereas it was just these locales that were bad, and the
generic handling was ok, or good enough. (The actual failures had the
radix be the two character string: apostrophe followed by a blank. It
would be a lot of work to make Perl deal with having a quote character
also mean a decimal point, and that work isn't worth it, especially as
this was a locale definition error, and we don't know of any locale in
the world where an apostrophe is legitimately a radix character.)
For this commit, I looked through the tests, and I added the tests where
it seemed that the problem could just be a bad locale definition to the
list of such tests. Note that failures here could mean an internal Perl
error, but in that case, it should affect many more locales, so will
show up anyway as the failure rate should exceed the acceptable one.
---
lib/locale.t | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/lib/locale.t b/lib/locale.t
index ae92eec..2b1724c 100644
--- a/lib/locale.t
+++ b/lib/locale.t
@@ -1621,12 +1621,15 @@ foreach my $Locale (@Locale) {
report_result($Locale, ++$locales_test_number, $ok3);
$test_names{$locales_test_number} = 'Verify that a different locale radix works when doing "==" with a constant';
+ $problematical_tests{$locales_test_number} = 1;
report_result($Locale, ++$locales_test_number, $ok4);
$test_names{$locales_test_number} = 'Verify that a different locale radix works when doing "==" with a scalar';
+ $problematical_tests{$locales_test_number} = 1;
report_result($Locale, ++$locales_test_number, $ok5);
$test_names{$locales_test_number} = 'Verify that a different locale radix works when doing "==" with a scalar and an intervening sprintf';
+ $problematical_tests{$locales_test_number} = 1;
debug "# $first_c_test..$locales_test_number: \$c = $c, \$d = $d, Locale = $Locale\n";
@@ -1639,24 +1642,30 @@ foreach my $Locale (@Locale) {
report_result($Locale, ++$locales_test_number, $ok8);
$test_names{$locales_test_number} = 'Verify that "==" with a scalar and an intervening sprintf still works in inner no locale';
+ $problematical_tests{$locales_test_number} = 1;
debug "# $first_e_test..$locales_test_number: \$e = $e, no locale\n";
report_result($Locale, ++$locales_test_number, $ok9);
$test_names{$locales_test_number} = 'Verify that after a no-locale block, a different locale radix still works when doing "==" with a constant';
+ $problematical_tests{$locales_test_number} = 1;
my $first_f_test = $locales_test_number;
report_result($Locale, ++$locales_test_number, $ok10);
$test_names{$locales_test_number} = 'Verify that after a no-locale block, a different locale radix still works when doing "==" with a scalar';
+ $problematical_tests{$locales_test_number} = 1;
report_result($Locale, ++$locales_test_number, $ok11);
$test_names{$locales_test_number} = 'Verify that after a no-locale block, a different locale radix still works when doing "==" with a scalar and an intervening sprintf';
+ $problematical_tests{$locales_test_number} = 1;
report_result($Locale, ++$locales_test_number, $ok12);
$test_names{$locales_test_number} = 'Verify that after a no-locale block, a different locale radix can participate in an addition and function call as numeric';
+ $problematical_tests{$locales_test_number} = 1;
report_result($Locale, ++$locales_test_number, $ok13);
$test_names{$locales_test_number} = 'Verify that don\'t get warning under "==" even if radix is not a dot';
+ $problematical_tests{$locales_test_number} = 1;
report_result($Locale, ++$locales_test_number, $ok14);
$test_names{$locales_test_number} = 'Verify that non-ASCII UTF-8 error messages are in UTF-8';
@@ -1849,6 +1858,7 @@ foreach my $Locale (@Locale) {
my @f = ();
++$locales_test_number;
$test_names{$locales_test_number} = 'Verify atof with locale radix and negative exponent';
+ $problematical_tests{$locales_test_number} = 1;
my $radix = POSIX::localeconv()->{decimal_point};
my @nums = (
--
1.8.3.2
|
From @jkeenanOn Mon Feb 24 11:23:02 2014, khw wrote:
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. |
From @khwilliamsonThe commit that actually fixed this was |
|
@khwilliamson - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#121079 (status was 'resolved')
Searchable as RT121079$
The text was updated successfully, but these errors were encountered: