Skip Menu |
Report information
Id: 119567
Status: resolved
Priority: 0/
Queue: perl5

Owner: Nobody
Requestors: dave.anglin [at] bell.net
Cc: dom <dom [at] earth.li>
AdminCc:

Operating System: Linux
PatchStatus: (no value)
Severity: low
Type: core
Perl Version: 5.18.1
Fixed In: (no value)



CC: dave.anglin [...] bell.net
Subject: lib/locale.t test failure with perl-5.18.1 on hppa-unknown-linux-gnu
Date: Mon, 2 Sep 2013 17:22:23 -0400
To: perlbug [...] perl.org
From: Dave Anglin <dave.anglin [...] bell.net>
Download (untitled) / with headers
text/plain 46.5k

Message body is not shown because it is too large.

RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 331b
According to comments on <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721537> this bug is already fixed in blead by commit 1500bd919ffeae0f3252f8d1bb28b03b043d328e by Karl Williamson. Does this sound plausible? If so, is this a candidate for backporting to maint-5.18? (The original bug fixed is #112208). Thanks, Dominic.
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 420b
On Sat Sep 07 10:14:22 2013, dom wrote: Show quoted text
> According to comments on > <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721537> > this bug is already fixed in blead by commit > 1500bd919ffeae0f3252f8d1bb28b03b043d328e by Karl Williamson. > > Does this sound plausible?
I don’t see how. Show quoted text
> If so, is this a candidate for backporting to > maint-5.18?
1500bd919ff is an incompatible change. -- Father Chrysostomos
CC: perl5-porters [...] perl.org
Subject: Re: [perl #119567] lib/locale.t test failure with perl-5.18.1 on hppa-unknown-linux-gnu
Date: Sat, 07 Sep 2013 12:06:35 -0600
To: perlbug-followup [...] perl.org
From: Karl Williamson <public [...] khwilliamson.com>
Download (untitled) / with headers
text/plain 1.3k
On 09/07/2013 11:23 AM, Father Chrysostomos via RT wrote: Show quoted text
> On Sat Sep 07 10:14:22 2013, dom wrote:
>> According to comments on >> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721537> >> this bug is already fixed in blead by commit >> 1500bd919ffeae0f3252f8d1bb28b03b043d328e by Karl Williamson. >> >> Does this sound plausible?
> > I don’t see how.
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 the error is reported as: lib/locale .................................................... Can't load '../lib/auto/re/re.so' for module re: ../lib/auto/re/re.so: failed to map segment from shared object: Cannot allocate memory at ../lib/XSLoader.pm line 68. at ../lib/re.pm line 85. Compilation failed in require at ../lib/utf8_heavy.pl line 4. BEGIN failed--compilation aborted at ../lib/utf8_heavy.pl line 4. Compilation failed in require at ../lib/utf8.pm line 17. It actually doesn't look like a locale problem; perhaps various changes just moved things around so that the problem doesn't happen. Have you tried running locale.t by hand? cd t ./perl -I../lib -T ../lib/locale.t Show quoted text
>
>> If so, is this a candidate for backporting to >> maint-5.18?
> > 1500bd919ff is an incompatible change. >
... which is controversial and likely to be reverted.
CC: perlbug-followup [...] perl.org
Subject: Re: [perl #119567] lib/locale.t test failure with perl-5.18.1 on hppa-unknown-linux-gnu
Date: Sat, 7 Sep 2013 20:08:26 +0100
To: John David Anglin <dave.anglin [...] bell.net>
From: Dominic Hargreaves <dom [...] earth.li>
Download (untitled) / with headers
text/plain 821b
On Sat, Sep 07, 2013 at 03:06:40PM -0400, John David Anglin wrote: Show quoted text
> On 7-Sep-13, at 2:07 PM, karl williamson via RT wrote: >
> >./perl -I../lib -T ../lib/locale.t
> > ... > ok 200 verify that isn't tainted > ok 201 verify that isn't tainted > Can't load '../lib/auto/re/re.so' for module re: > ../lib/auto/re/re.so: failed to map segment from shared object: > Cannot allocate memory at ../lib/XSLoader.pm line 68. > at ../lib/re.pm line 85. > Compilation failed in require at ../lib/utf8_heavy.pl line 4. > BEGIN failed--compilation aborted at ../lib/utf8_heavy.pl line 4. > Compilation failed in require at ../lib/utf8.pm line 16. > > Same output with LANG=C. > > This is with 69edd4754eb5832038093138e75d8325269476a4. > > My messages to perbug-followup@perl.org are being dropped.
More likely held in a queue.
Subject: Re: [perl #119567] perlbug AutoReply: lib/locale.t test failure with perl-5.18.1 on hppa-unknown-linux-gnu
Date: Sat, 7 Sep 2013 09:02:11 -0400
To: perlbug-followup [...] perl.org
From: John David Anglin <dave.anglin [...] bell.net>
Download (untitled) / with headers
text/plain 1.3k
Based on my testing, this bug was fixed on mainline with the following commit: commit 1500bd919ffeae0f3252f8d1bb28b03b043d328e Author: Karl Williamson <public@khwilliamson.com> Date: Wed Jun 19 21:00:53 2013 -0600 PATCH: [perl #112208]: Set utf8 flag on $! appropriately This patch sets the utf8 flag on $! if the error string passes utf8 validity tests and has some bytes with the upper bit set. (If none have that bit set, is an ASCII string, and whether or not it is UTF-8 is irrelevant.) This is a heuristic that could fail, but as the reference in the comments points out this is unlikely. One can reasonably assume that a UTF-8 locale will return a UTF-8 result. So another approach would be to look at that (but we wouldn't want to turn the flag on for a purely ASCII string anyway, as that could change the semantics from existing behavior by making the string follow Unicode rules, whereas it didn't necessarily before.) To do this, we could keep track of the utf8ness of the LC_MESSAGES locale. But until the heuristic in this patch is shown to not be good enough, I don't see the need to do this extra work. There were a number of other locale related patches just prior to this one. This bug breaks package build on Debian, so maybe a back port is justified. Dave -- John David Anglin dave.anglin@bell.net
CC: dom [...] earth.li
Subject: Re: [perl #119567] lib/locale.t test failure with perl-5.18.1 on hppa-unknown-linux-gnu
Date: Sat, 7 Sep 2013 13:37:46 -0400
To: perlbug-followup [...] perl.org
From: John David Anglin <dave.anglin [...] bell.net>
Download (untitled) / with headers
text/plain 821b
On 7-Sep-13, at 1:23 PM, Father Chrysostomos via RT wrote: Show quoted text
> On Sat Sep 07 10:14:22 2013, dom wrote:
>> According to comments on >> <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=721537> >> this bug is already fixed in blead by commit >> 1500bd919ffeae0f3252f8d1bb28b03b043d328e by Karl Williamson. >> >> Does this sound plausible?
> > I don’t see how.
Found by bisection of git tree. dave@mx3210:~/perl/perl-test$ locale LANG=en_CA.UTF-8 LANGUAGE= LC_CTYPE="en_CA.UTF-8" LC_NUMERIC="en_CA.UTF-8" LC_TIME="en_CA.UTF-8" LC_COLLATE="en_CA.UTF-8" LC_MONETARY="en_CA.UTF-8" LC_MESSAGES="en_CA.UTF-8" LC_PAPER="en_CA.UTF-8" LC_NAME="en_CA.UTF-8" LC_ADDRESS="en_CA.UTF-8" LC_TELEPHONE="en_CA.UTF-8" LC_MEASUREMENT="en_CA.UTF-8" LC_IDENTIFICATION="en_CA.UTF-8" LC_ALL= Dave -- John David Anglin dave.anglin@bell.net
CC: dom [...] earth.li
Subject: Re: [perl #119567] lib/locale.t test failure with perl-5.18.1 on hppa-unknown-linux-gnu
Date: Sat, 7 Sep 2013 15:06:40 -0400
To: perlbug-followup [...] perl.org
From: John David Anglin <dave.anglin [...] bell.net>
Download (untitled) / with headers
text/plain 740b
On 7-Sep-13, at 2:07 PM, karl williamson via RT wrote: Show quoted text
> ./perl -I../lib -T ../lib/locale.t
... ok 200 verify that isn't tainted ok 201 verify that isn't tainted Can't load '../lib/auto/re/re.so' for module re: ../lib/auto/re/re.so: failed to map segment from shared object: Cannot allocate memory at ../ lib/XSLoader.pm line 68. at ../lib/re.pm line 85. Compilation failed in require at ../lib/utf8_heavy.pl line 4. BEGIN failed--compilation aborted at ../lib/utf8_heavy.pl line 4. Compilation failed in require at ../lib/utf8.pm line 16. Same output with LANG=C. This is with 69edd4754eb5832038093138e75d8325269476a4. My messages to perbug-followup@perl.org are being dropped. Dave -- John David Anglin dave.anglin@bell.net
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 411b
FYI 1500bd919ffeae0f3252f8d1bb28b03b043d328e is going to be reverted https://rt.perl.org/rt3/Ticket/Display.html?id=119499#txn-1252975 On Mon Sep 09 23:16:17 2013, dave.anglin@bell.net wrote: Show quoted text
> Based on my testing, this bug was fixed on mainline with the following > commit 1500bd919ffeae0f3252f8d1bb28b03b043d328e > Author: Karl Williamson <public@khwilliamson.com> > Date: Wed Jun 19 21:00:53 2013 -0600
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 924b
On Tue Sep 10 01:44:54 2013, vsespb wrote: Show quoted text
> FYI 1500bd919ffeae0f3252f8d1bb28b03b043d328e is going to be reverted > https://rt.perl.org/rt3/Ticket/Display.html?id=119499#txn-1252975 > > On Mon Sep 09 23:16:17 2013, dave.anglin@bell.net wrote:
> > Based on my testing, this bug was fixed on mainline with the following > > commit 1500bd919ffeae0f3252f8d1bb28b03b043d328e > > Author: Karl Williamson <public@khwilliamson.com> > > Date: Wed Jun 19 21:00:53 2013 -0600
It's almost certainly not the case that this commit actually "fixed" the problem. Much more plausible is that it perturbs things so the real cause doesn't happen here. That means the bug is waiting to bite again under the right circumstances. Since you have git, I suggest manually reverting this patch yourself on blead as an experiment and see if the failure returns. Depending on that result, we can figure out how to proceed. -- Karl Williamson
CC: dom [...] earth.li
Subject: Re: [perl #119567] lib/locale.t test failure with perl-5.18.1 on hppa-unknown-linux-gnu
Date: Tue, 10 Sep 2013 13:44:05 -0400
To: perlbug-followup [...] perl.org
From: John David Anglin <dave.anglin [...] bell.net>
Download (untitled) / with headers
text/plain 420b
On 9/10/2013 1:18 PM, Karl Williamson via RT wrote: Show quoted text
> It's almost certainly not the case that this commit actually "fixed" the > problem. Much more plausible is that it perturbs things so the real > cause doesn't happen here.
What I suspect is a mmap call with the MAP_FIXED flag is failing. Maybe I can find this with strace. The "addr" argument may be changing. Dave -- John David Anglin dave.anglin@bell.net
CC: perlbug-followup [...] perl.org, dom [...] earth.li
Subject: Re: [perl #119567] lib/locale.t test failure with perl-5.18.1 on hppa-unknown-linux-gnu
Date: Tue, 10 Sep 2013 21:36:27 -0400
To: John David Anglin <dave.anglin [...] bell.net>
From: John David Anglin <dave.anglin [...] bell.net>
Download (untitled) / with headers
text/plain 1.1k
On 10-Sep-13, at 1:44 PM, John David Anglin wrote: Show quoted text
> On 9/10/2013 1:18 PM, Karl Williamson via RT wrote:
>> It's almost certainly not the case that this commit actually >> "fixed" the >> problem. Much more plausible is that it perturbs things so the real >> cause doesn't happen here.
> What I suspect is a mmap call with the MAP_FIXED flag is failing. > Maybe I can find this with strace. The "addr" argument may be > changing.
It's not MAP_FIXED. Looking at the strace output, I see the application is running out of memory: open("/usr/lib/locale/de_LI.utf8/LC_ADDRESS", O_RDONLY|O_CLOEXEC) = 4fstat64(4, {st_mode=0, st_size=0, ...}) = 0 mmap(NULL, 127, PROT_READ, MAP_PRIVATE, 4, 0) = 0xffe93000 close(4) = 0 open("/usr/lib/locale/de_LI.utf8/LC_NAME", O_RDONLY|O_CLOEXEC) = 4fstat64(4, {st_mode=0, st_size=0, ...}) = 0 mmap(NULL, 62, PROT_READ, MAP_PRIVATE, 4, 0) = -1 ENOMEM (Cannot allocate memory ) There are a lot of small allocations but because of aliasing issues, the kernel allocates much larger maps than other systems. I tend to think there's a kernel bug here but I'm not sure. Dave -- John David Anglin dave.anglin@bell.net
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.4k
On Tue Sep 10 21:53:02 2013, dave.anglin@bell.net wrote: Show quoted text
> On 10-Sep-13, at 1:44 PM, John David Anglin wrote: >
> > On 9/10/2013 1:18 PM, Karl Williamson via RT wrote:
> >> It's almost certainly not the case that this commit actually > >> "fixed" the > >> problem. Much more plausible is that it perturbs things so the real > >> cause doesn't happen here.
> > What I suspect is a mmap call with the MAP_FIXED flag is failing. > > Maybe I can find this with strace. The "addr" argument may be > > changing.
> > > It's not MAP_FIXED. Looking at the strace output, I see the > application is > running out of memory: > > open("/usr/lib/locale/de_LI.utf8/LC_ADDRESS", O_RDONLY|O_CLOEXEC) = > 4fstat64(4, {st_mode=0, st_size=0, ...}) = 0 > mmap(NULL, 127, PROT_READ, MAP_PRIVATE, 4, 0) = 0xffe93000 > close(4) = 0 > open("/usr/lib/locale/de_LI.utf8/LC_NAME", O_RDONLY|O_CLOEXEC) = > 4fstat64(4, {st_mode=0, st_size=0, ...}) = 0 > mmap(NULL, 62, PROT_READ, MAP_PRIVATE, 4, 0) = -1 ENOMEM (Cannot > allocate memory > ) > > There are a lot of small allocations but because of aliasing issues, > the kernel allocates much larger maps than other > systems. I tend to think there's a kernel bug here but I'm not sure. > > Dave > -- > John David Anglin dave.anglin@bell.net > > >
Is there any progress on this bug. If you've decided it's not a Perl bug, can we close it? -- Karl Williamson
CC: dom [...] earth.li
Subject: Re: [perl #119567] lib/locale.t test failure with perl-5.18.1 on hppa-unknown-linux-gnu
Date: Tue, 15 Oct 2013 08:10:44 -0400
To: perlbug-followup [...] perl.org
From: John David Anglin <dave.anglin [...] bell.net>
On 14-Oct-13, at 11:11 PM, Karl Williamson via RT wrote: Show quoted text
> On Tue Sep 10 21:53:02 2013, dave.anglin@bell.net wrote:
>> On 10-Sep-13, at 1:44 PM, John David Anglin wrote: >>
>>> On 9/10/2013 1:18 PM, Karl Williamson via RT wrote:
>>>> It's almost certainly not the case that this commit actually >>>> "fixed" the >>>> problem. Much more plausible is that it perturbs things so the >>>> real >>>> cause doesn't happen here.
>>> What I suspect is a mmap call with the MAP_FIXED flag is failing. >>> Maybe I can find this with strace. The "addr" argument may be >>> changing.
>> >> >> It's not MAP_FIXED. Looking at the strace output, I see the >> application is >> running out of memory: >> >> open("/usr/lib/locale/de_LI.utf8/LC_ADDRESS", O_RDONLY|O_CLOEXEC) = >> 4fstat64(4, {st_mode=0, st_size=0, ...}) = 0 >> mmap(NULL, 127, PROT_READ, MAP_PRIVATE, 4, 0) = 0xffe93000 >> close(4) = 0 >> open("/usr/lib/locale/de_LI.utf8/LC_NAME", O_RDONLY|O_CLOEXEC) = >> 4fstat64(4, {st_mode=0, st_size=0, ...}) = 0 >> mmap(NULL, 62, PROT_READ, MAP_PRIVATE, 4, 0) = -1 ENOMEM (Cannot >> allocate memory >> ) >> >> There are a lot of small allocations but because of aliasing issues, >> the kernel allocates much larger maps than other >> systems. I tend to think there's a kernel bug here but I'm not sure. >> >> Dave >> -- >> John David Anglin dave.anglin@bell.net >> >> >>
> > Is there any progress on this bug. If you've decided it's not a Perl > bug, can we close it?
Not on my part. I'm not convinced this isn't a Perl bug in that it's showing the limitations of the mapping scheme currently used for locales. Although it it might be possible to improve the mmap allocation on parisc linux, this is very tricky. There are kernel limits on the number of files, vma's, etc. Most applications that do a lot of allocations use their own allocator and garbage collection. I believe that all glibc locales are installed on the machine where I see the failure? Dave -- John David Anglin dave.anglin@bell.net
CC: dom [...] earth.li
Subject: Re: [perl #119567] lib/locale.t test failure with perl-5.18.1 on hppa-unknown-linux-gnu
Date: Thu, 17 Oct 2013 22:59:03 -0400
To: perlbug-followup [...] perl.org
From: John David Anglin <dave.anglin [...] bell.net>
Download (untitled) / with headers
text/plain 352b
On 14-Oct-13, at 11:11 PM, Karl Williamson via RT wrote: Show quoted text
> Is there any progress on this bug. If you've decided it's not a Perl > bug, can we close it?
The test fails in part due to the number of locale files on my machine. Roughly, mmap fails with ENOMEM after about 1300 files are processed. Dave -- John David Anglin dave.anglin@bell.net
Date: Thu, 14 Nov 2013 22:31:54 -0700
From: Karl Williamson <public [...] khwilliamson.com>
Subject: Re: [perl #119567] lib/locale.t test failure with perl-5.18.1 on hppa-unknown-linux-gnu
To: John David Anglin <dave.anglin [...] bell.net>, perlbug-followup [...] perl.org
CC: dom [...] earth.li
Download (untitled) / with headers
text/plain 1.1k
On 10/17/2013 08:59 PM, John David Anglin wrote: Show quoted text
> On 14-Oct-13, at 11:11 PM, Karl Williamson via RT wrote: >
>> Is there any progress on this bug. If you've decided it's not a Perl >> bug, can we close it?
> > > The test fails in part due to the number of locale files on my machine. > Roughly, > mmap fails with ENOMEM after about 1300 files are processed. >
Sorry for the tardy response. That's a lot of locales. Unicode CLDR publishes somewhat over 700 that are supposed to sufficiently encode the whole world. The failing test file is designed to go through all the locales on a machine testing that each works. It saves up the results and will output a report. A quick perusal didn't show obvious places where it is saving information unnecessarily, though it could well be. It's also possible that libc uses up memory for each locale tried, and which doesn't get released when a different locale is set. I'm not sure how to proceed. You could try not using all the locales. The easiest way to do this that comes to mind is to add the following line as the first one in the sub trylocale(). return if @Locale > 500; or some other number.
From: John David Anglin <dave.anglin [...] bell.net>
CC: dom [...] earth.li
To: perlbug-followup [...] perl.org
Subject: Re: [perl #119567] lib/locale.t test failure with perl-5.18.1 on hppa-unknown-linux-gnu
Date: Sat, 16 Nov 2013 18:01:43 -0500
Download (untitled) / with headers
text/plain 1.2k
On 15-Nov-13, at 12:32 AM, karl williamson via RT wrote: Show quoted text
> That's a lot of locales. Unicode CLDR publishes somewhat over 700 > that > are supposed to sufficiently encode the whole world.
There aren't that many locales on my machine. There are multiple files per locale. Show quoted text
> > The failing test file is designed to go through all the locales on a > machine testing that each works. It saves up the results and will > output a report. > > A quick perusal didn't show obvious places where it is saving > information unnecessarily, though it could well be. It's also > possible > that libc uses up memory for each locale tried, and which doesn't get > released when a different locale is set.
I think the libc issue needs looking at. I looked at a kernel patch but it's somewhat dangerous on hppa. It introduces inequivalent mappings in situations and is dangerous when the file is mapped readonly and shared. Show quoted text
> > I'm not sure how to proceed. You could try not using all the locales. > The easiest way to do this that comes to mind is to add the following > line as the first one in the sub trylocale(). > > return if @Locale > 500;
I'll try to come up with a number. Dave -- John David Anglin dave.anglin@bell.net
RT-Send-CC: perl5-porters [...] perl.org
Download (untitled) / with headers
text/plain 1.5k
On Sat Nov 16 15:02:52 2013, dave.anglin@bell.net wrote: Show quoted text
> > On 15-Nov-13, at 12:32 AM, karl williamson via RT wrote: >
> > That's a lot of locales. Unicode CLDR publishes somewhat over 700 > > that > > are supposed to sufficiently encode the whole world.
> > There aren't that many locales on my machine. There are multiple > files per > locale. >
> > > > The failing test file is designed to go through all the locales on a > > machine testing that each works. It saves up the results and will > > output a report. > > > > A quick perusal didn't show obvious places where it is saving > > information unnecessarily, though it could well be. It's also > > possible > > that libc uses up memory for each locale tried, and which doesn't get > > released when a different locale is set.
> > I think the libc issue needs looking at. I looked at a kernel patch but > it's somewhat dangerous on hppa. It introduces inequivalent > mappings in situations and is dangerous when the file is mapped > readonly and shared. >
> > > > I'm not sure how to proceed. You could try not using all the locales. > > The easiest way to do this that comes to mind is to add the following > > line as the first one in the sub trylocale(). > > > > return if @Locale > 500;
> > I'll try to come up with a number. > > Dave > -- > John David Anglin dave.anglin@bell.net > > >
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? -- Karl Williamson
From: John David Anglin <dave.anglin [...] bell.net>
CC: dom [...] earth.li
Subject: Re: [perl #119567] lib/locale.t test failure with perl-5.18.1 on hppa-unknown-linux-gnu
To: perlbug-followup [...] perl.org
Date: Mon, 10 Mar 2014 22:41:57 -0400
Download (untitled) / with headers
text/plain 2.6k
On 10-Mar-14, at 7:07 PM, Karl Williamson via RT wrote: Show quoted text
> On Sat Nov 16 15:02:52 2013, dave.anglin@bell.net wrote:
>> >> On 15-Nov-13, at 12:32 AM, karl williamson via RT wrote: >>
>>> That's a lot of locales. Unicode CLDR publishes somewhat over 700 >>> that >>> are supposed to sufficiently encode the whole world.
>> >> There aren't that many locales on my machine. There are multiple >> files per >> locale. >>
>>> >>> The failing test file is designed to go through all the locales on a >>> machine testing that each works. It saves up the results and will >>> output a report. >>> >>> A quick perusal didn't show obvious places where it is saving >>> information unnecessarily, though it could well be. It's also >>> possible >>> that libc uses up memory for each locale tried, and which doesn't >>> get >>> released when a different locale is set.
>> >> I think the libc issue needs looking at. I looked at a kernel >> patch but >> it's somewhat dangerous on hppa. It introduces inequivalent >> mappings in situations and is dangerous when the file is mapped >> readonly and shared. >>
>>> >>> I'm not sure how to proceed. You could try not using all the >>> locales. >>> The easiest way to do this that comes to mind is to add the >>> following >>> line as the first one in the sub trylocale(). >>> >>> return if @Locale > 500;
>> >> I'll try to come up with a number. >> >> Dave >> -- >> John David Anglin dave.anglin@bell.net >> >> >>
> > 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?
I built blead tonight and ran tests. The good news is the lib/locale test didn't fail. The bad news is there is one new fail: Failed 1 test out of 2263, 99.96% okay. ../cpan/Math-Complex/t/Trig.t Running manually, I see: not ok 130 # Failed test at ../cpan/Math-Complex/t/Trig.t line 342. # got: -5e+299 # expected: -inf not ok 131 # Failed test at ../cpan/Math-Complex/t/Trig.t line 343. # got: 2e-300 # expected: 0 not ok 132 # Failed test at ../cpan/Math-Complex/t/Trig.t line 344. # got: 5e+299 # expected: inf not ok 133 # Failed test at ../cpan/Math-Complex/t/Trig.t line 345. # got: -2e-300 # expected: 0 Looks like various corner cases fail but it's too late to investigate further. Helge Deller has made some progress in improving the mmap allocations for small files. I don't have the change installed. It involves changes to the linux core so I don't know how far he will get with it. Regards, Dave -- John David Anglin dave.anglin@bell.net
From: Karl Williamson <public [...] khwilliamson.com>
To: John David Anglin <dave.anglin [...] bell.net>, perlbug-followup [...] perl.org
Date: Mon, 10 Mar 2014 20:48:14 -0600
Subject: Re: [perl #119567] lib/locale.t test failure with perl-5.18.1 on hppa-unknown-linux-gnu
CC: dom [...] earth.li
Download (untitled) / with headers
text/plain 2.8k
On 03/10/2014 08:41 PM, John David Anglin wrote: Show quoted text
> On 10-Mar-14, at 7:07 PM, Karl Williamson via RT wrote: >
>> On Sat Nov 16 15:02:52 2013, dave.anglin@bell.net wrote:
>>> >>> On 15-Nov-13, at 12:32 AM, karl williamson via RT wrote: >>>
>>>> That's a lot of locales. Unicode CLDR publishes somewhat over 700 >>>> that >>>> are supposed to sufficiently encode the whole world.
>>> >>> There aren't that many locales on my machine. There are multiple >>> files per >>> locale. >>>
>>>> >>>> The failing test file is designed to go through all the locales on a >>>> machine testing that each works. It saves up the results and will >>>> output a report. >>>> >>>> A quick perusal didn't show obvious places where it is saving >>>> information unnecessarily, though it could well be. It's also >>>> possible >>>> that libc uses up memory for each locale tried, and which doesn't get >>>> released when a different locale is set.
>>> >>> I think the libc issue needs looking at. I looked at a kernel patch but >>> it's somewhat dangerous on hppa. It introduces inequivalent >>> mappings in situations and is dangerous when the file is mapped >>> readonly and shared. >>>
>>>> >>>> I'm not sure how to proceed. You could try not using all the locales. >>>> The easiest way to do this that comes to mind is to add the following >>>> line as the first one in the sub trylocale(). >>>> >>>> return if @Locale > 500;
>>> >>> I'll try to come up with a number. >>> >>> Dave >>> -- >>> John David Anglin dave.anglin@bell.net >>> >>> >>>
>> >> 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?
> > I built blead tonight and ran tests. The good news is the lib/locale > test didn't fail. The bad news is > there is one new fail: > > Failed 1 test out of 2263, 99.96% okay. > ../cpan/Math-Complex/t/Trig.t > > Running manually, I see: > > not ok 130 > # Failed test at ../cpan/Math-Complex/t/Trig.t line 342. > # got: -5e+299 > # expected: -inf > not ok 131 > # Failed test at ../cpan/Math-Complex/t/Trig.t line 343. > # got: 2e-300 > # expected: 0 > not ok 132 > # Failed test at ../cpan/Math-Complex/t/Trig.t line 344. > # got: 5e+299 > # expected: inf > not ok 133 > # Failed test at ../cpan/Math-Complex/t/Trig.t line 345. > # got: -2e-300 > # expected: 0 > > Looks like various corner cases fail but it's too late to investigate > further. > > Helge Deller has made some progress in improving the mmap allocations for > small files. I don't have the change installed. It involves changes to > the linux > core so I don't know how far he will get with it. > > Regards, > Dave > -- > John David Anglin dave.anglin@bell.net > > >
I'll close this ticket then; you should open a new one for the unrelated failures.
RT-Send-CC: perl5-porters [...] perl.org
Reported fixed by OP -- Karl Williamson


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

For issues related to this RT instance (aka "perlbug"), please contact perlbug-admin at perl.org