lib/locale.t: Test failures in threaded builds on FreeBSD 10.3 #15500
Comments
From @jkeenanYesterday, for the first time I was able to smoke test Perl 5 blead on FreeBSD 10.3. This OS is a virtual machine hosted on a Linux x86_64 machine. All tests PASSed on non-threaded builds, but there were failures in lib/locale.t on threaded builds. The relevant smoke test report may be found at: http://perl5.test-smoke.org/report/48882. Note that the "FAILED 439" in that report apparently means that the first failure occurred at test 439 -- not that there were 439 failures overall. There were 7 failures in each of 4 different variations of threaded builds. Per previous coaching from Karl Williamson, I re-ran the failing test file with PERL_DEBUG_FULL_TEST=2. The output, as expected, is enormous, so I'll only send that to khw and to anyone else who requests it. I'm attaching a reduced version of that output as well as the 'perl -V' output for that build. Thank you very much. |
From @jkeenan$ cd t;./perl harness -v ../lib/locale.t; cd - # lower=FF; uc=178; ; fc=FF; FF= Failed 7/682 subtests Test Summary Report ../lib/locale.t (Wstat: 0 Tests: 682 Failed: 7) |
From @jkeenanSummary of my perl5 (revision 5 version 25 subversion 4) configuration: Characteristics of this binary (from libperl): |
From @khwilliamsonA bug report has been file against freebsd |
From @khwilliamson#include <stdio.h>
#include <locale.h>
#include <string.h>
int
main(int argc, char **argv)
{
int i;
locale_t C_locale_object = newlocale(LC_ALL_MASK, "C", NULL);
setlocale(LC_MESSAGES, "be_BY.UTF-8");
uselocale(C_locale_object);
for (i=1; i < 10; i++) {
/* This should print using the C locale, hence in ASCII */
printf("%s\n", strerror(i));
}
}
|
|
The RT System itself - Status changed from 'new' to 'open' |
From @cpansproutOn Wed Aug 10 16:57:45 2016, khw wrote:
In what way does the attached program misbehave (for the sake of future readers)? Is there any way to work around the issue in perl, so that it passes tests (without skipping them) on current FreeBSDs? -- Father Chrysostomos |
From @cpansproutOn Wed Aug 10 19:52:33 2016, sprout wrote:
I see you have committed 7536d89. -- Father Chrysostomos |
From @jkeenanOn Wed Aug 10 19:52:33 2016, sprout wrote:
1. Let me, as the original poster, take a stab at answering this. (khw can offer more details.) Disclaimer: I am not a C expert; I'm working from an initial reading of the relevant man pages (both Linux and FreeBSD). a. The program creates a new locale object in the "C" locale. b. The program then requests that localizable natural-language messages be rendered in Byelorussian UTF-8. c. The program then sets the current locale for the calling thread to that in the locale object created in 'a' above. Presumably this means that error messages will be rendered in the "C" locale's way, not in Byelorussian. d. We see what actually happens by looping through 9 error messages. On Linux (Ubuntu 16.04 LTS), running the compiled program produces: ##### On a Vagrant box containing FreeBSD 10.3, hosted on that Linux machine, I get: ##### On the same version of FreeBSD 10.3, run inside a VirtualBox 5.1 VM *not* accessed by Vagrant, I get gobbledygook which I'll simply post here: So it appears that the 'uselocale' call on FreeBSD is not DWIMming. Until we can get clarification from FreeBSD folks about this, we'll use this hint provided by khw: ##### I should add that, because we were not getting smoke tests about FreeBSD until I started providing them this month, and because the only VMs I have of FreeBSD are 10.3, we can't exactly say when this problem first appeared. Thank you very much. -- |
From @khwilliamsonOn 08/11/2016 07:28 AM, James E Keenan via RT wrote:
A complete description of the problem and the program are at the link I If it helps, you can kind of think of it this way: A locale walks into a bar and orders some C, straight up. |
From @maukeAm 11.08.2016 um 15:28 schrieb James E Keenan via RT:
That gobbledygook is the same Byelorussian strings you showed above, I can reproduce it using -- |
From @khwilliamsonFreeBSD now passes, based on the workaround I added in 7536d89. |
|
@khwilliamson - Status changed from 'open' to 'resolved' |
From @jkeenanOn 08/11/2016 01:20 PM, Karl Williamson via RT wrote:
Here is the smoke report supporting the above: |
From @khwilliamsonOn 08/11/2016 11:43 AM, James E Keenan wrote:
I had already seen it, which is why I closed the ticket. I look at |
From @khwilliamsonThis was fixed in freebsd : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211743 It also turned up in dragonfly, and was fixed https://gitweb.dragonflybsd.org/dragonfly.git/commit/21a0e97de9138e49c0f26ecb49e6cbba2478f410 Attached is a test file that reproduces the problem, so we don't have to write a new one for any other buggy systems out there |
From @khwilliamson#include <stdio.h>
#include <string.h>
#include <stdlib.h>
#include <locale.h>
int main (int argc, char **argv) {
if (argc != 2) {
fprintf(stderr, "Usage: $0 errno-value\n");
exit(2);
}
printf("%s: %d: Setting global locale to %s\n", __FILE__, __LINE__, setlocale(LC_ALL, "C"));
locale_t PL_C_locale_obj = newlocale(LC_ALL_MASK, "C", (locale_t) NULL);
printf("%s: %d: Created a locale object for the C locale: %p\n", __FILE__, __LINE__, PL_C_locale_obj);
printf("%s: %d: Setting global locale to %s\n", __FILE__, __LINE__, setlocale(LC_ALL, "be_BY.UTF-8"));
printf("%s: %d: This should print in Belarussion: %s\n", __FILE__, __LINE__, strerror(atoi(argv[1])));
printf("%s: %d: Changing thread locale to C, previous one should be -1 for global: %p\n", __FILE__, __LINE__, uselocale(PL_C_locale_obj));
printf("%s: %d: Confirming that the thread locale was changed: %p\n", __FILE__, __LINE__, uselocale((locale_t) 0));
printf("%s: %d: This should print in ASCII: %s\n", __FILE__, __LINE__, strerror(atoi(argv[1])));
}
|
Migrated from rt.perl.org#128867 (status was 'resolved')
Searchable as RT128867$
The text was updated successfully, but these errors were encountered: