New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lib/locale.t test failure with perl-5.18.1 on hppa-unknown-linux-gnu #13220
Comments
From dave.anglin@bell.netCreated by dave.anglin@bell.netThe following test failure occurs running tests with perl 5.18.1: Can't load '../lib/auto/re/re.so' for module re: ../lib/auto/re/re.so: failed to The problem can be reproduced using a simple configuration: The failure doesn't occur with "blead". It also wasn't present in 5.14.2. I think it's unlikely that this is a simple memory allocation issue: dave@mx3210:~/perl/perl5$ ulimit -a Failure is consistent. Perl Info
|
From @jmdhAccording to comments on Does this sound plausible? If so, is this a candidate for backporting to Thanks, |
The RT System itself - Status changed from 'new' to 'open' |
From @cpansproutOn Sat Sep 07 10:14:22 2013, dom wrote:
I don’t see how.
1500bd9 is an incompatible change. -- Father Chrysostomos |
From @khwilliamsonOn 09/07/2013 11:23 AM, Father Chrysostomos via RT wrote:
Me neither. Did you run a bisect that pointed to this commit? For reference for those not wanting to look at the ticket, here is what lib/locale .................................................... Can't It actually doesn't look like a locale problem; perhaps various changes Have you tried running locale.t by hand? cd t
... which is controversial and likely to be reverted. |
From @jmdhOn Sat, Sep 07, 2013 at 03:06:40PM -0400, John David Anglin wrote:
More likely held in a queue. |
From dave.anglin@bell.netBased on my testing, this bug was fixed on mainline with the following commit 1500bd9 PATCH: [perl #112208]: Set utf8 flag on $! appropriately This patch sets the utf8 flag on $! if the error string passes utf8 One can reasonably assume that a UTF-8 locale will return a UTF-8 There were a number of other locale related patches just prior to this This bug breaks package build on Debian, so maybe a back port is Dave |
From dave.anglin@bell.netOn 7-Sep-13, at 1:23 PM, Father Chrysostomos via RT wrote:
Found by bisection of git tree. dave@mx3210:~/perl/perl-test$ locale Dave |
From dave.anglin@bell.netOn 7-Sep-13, at 2:07 PM, karl williamson via RT wrote:
... Same output with LANG=C. This is with 69edd47. My messages to perbug-followup@perl.org are being dropped. Dave |
From victor@vsespb.ruFYI 1500bd9 is going to be reverted On Mon Sep 09 23:16:17 2013, dave.anglin@bell.net wrote:
|
From @khwilliamsonOn Tue Sep 10 01:44:54 2013, vsespb wrote:
It's almost certainly not the case that this commit actually "fixed" the |
From dave.anglin@bell.netOn 9/10/2013 1:18 PM, Karl Williamson via RT wrote:
Dave -- |
From dave.anglin@bell.netOn 10-Sep-13, at 1:44 PM, John David Anglin wrote:
It's not MAP_FIXED. Looking at the strace output, I see the open("/usr/lib/locale/de_LI.utf8/LC_ADDRESS", O_RDONLY|O_CLOEXEC) = There are a lot of small allocations but because of aliasing issues, Dave |
From @khwilliamsonOn Tue Sep 10 21:53:02 2013, dave.anglin@bell.net wrote:
Is there any progress on this bug. If you've decided it's not a Perl -- |
From dave.anglin@bell.netOn 14-Oct-13, at 11:11 PM, Karl Williamson via RT wrote:
Not on my part. I'm not convinced this isn't a Perl bug in that it's showing the Although it it might be possible to improve the mmap allocation on There are kernel limits on the number of files, vma's, etc. Most applications that do a lot of allocations use their own allocator I believe that all glibc locales are installed on the machine where I Dave |
From dave.anglin@bell.netOn 14-Oct-13, at 11:11 PM, Karl Williamson via RT wrote:
The test fails in part due to the number of locale files on my Dave |
From @khwilliamsonOn 10/17/2013 08:59 PM, John David Anglin wrote:
Sorry for the tardy response. That's a lot of locales. Unicode CLDR publishes somewhat over 700 that The failing test file is designed to go through all the locales on a A quick perusal didn't show obvious places where it is saving I'm not sure how to proceed. You could try not using all the locales. return if @Locale > 500; or some other number. |
From dave.anglin@bell.netOn 15-Nov-13, at 12:32 AM, karl williamson via RT wrote:
There aren't that many locales on my machine. There are multiple
I think the libc issue needs looking at. I looked at a kernel patch but
I'll try to come up with a number. Dave |
From @khwilliamsonOn Sat Nov 16 15:02:52 2013, dave.anglin@bell.net wrote:
FYI, there have been many changes in the .t since this bug was filed. Perhaps it has been fixed or no longer shows up as a result. Could you test with blead and let us know? |
From dave.anglin@bell.netOn 10-Mar-14, at 7:07 PM, Karl Williamson via RT wrote:
I built blead tonight and ran tests. The good news is the lib/locale Failed 1 test out of 2263, 99.96% okay. Running manually, I see: not ok 130 Looks like various corner cases fail but it's too late to investigate Helge Deller has made some progress in improving the mmap allocations Regards, |
From @khwilliamsonOn 03/10/2014 08:41 PM, John David Anglin wrote:
I'll close this ticket then; you should open a new one for the unrelated |
From @khwilliamsonReported fixed by OP |
@khwilliamson - Status changed from 'open' to 'resolved' |
Migrated from rt.perl.org#119567 (status was 'resolved')
Searchable as RT119567$
The text was updated successfully, but these errors were encountered: