Skip Menu |
 

This queue is for tickets about the Locked-Storage CPAN distribution.

Report information
The Basics
Id: 128467
Status: resolved
Priority: 0/
Queue: Locked-Storage

People
Owner: cpan [...] sorbs.net
Requestors: SREZIC [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: t/03-store-get.t fails on most systems (1.07)
Download (untitled) / with headers
text/plain 400b
On most of my smokers t/03-store-get.t fails: ... # Failed test 'Retrieve Data' # at t/03-store-get.t line 15. # got: undef # expected: 'Hello World!' # Looks like you failed 1 test of 2. t/03-store-get.t .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/2 subtests ... There are a couple of systems where this test is passing, however I don't see a os/perlversion pattern.
Subject: Re: [rt.cpan.org #128467] t/03-store-get.t fails on most systems (1.07)
Date: Sun, 10 Feb 2019 03:37:50 +1100
To: bug-Locked-Storage [...] rt.cpan.org
From: Michelle Sullivan <michelle [...] sorbs.net>
Slaven_Rezic via RT wrote: Show quoted text
> Sat Feb 09 11:21:49 2019: Request 128467 was acted upon. > Transaction: Ticket created by SREZIC > Queue: Locked-Storage > Subject: t/03-store-get.t fails on most systems (1.07) > Broken in: (no value) > Severity: (no value) > Owner: Nobody > Requestors: SREZIC@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=128467 > > > > On most of my smokers t/03-store-get.t fails: > > ... > # Failed test 'Retrieve Data' > # at t/03-store-get.t line 15. > # got: undef > # expected: 'Hello World!' > # Looks like you failed 1 test of 2. > t/03-store-get.t .. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/2 subtests > ... > > There are a couple of systems where this test is passing, however I don't see a os/perlversion pattern.
Hmm.. you'd need to check the memory (possibly using $ls->dump) to see if the store actually put the data in the memory - I think I need to really pull my finger out and check for OS errors (I wrote it as something quick for a project I'm working on which it just works on) it's possible that the os/perlversion pattern might present itself when you check the default page size vs RLIMIT_MEMLOCK for a user.... because of the fact the fact mlock() will only lock a page (multiples thereof) I don't set what bytes are requested instead allocating a full page (multiple therefore based on the ->new parameter).. if the default pagesize is larger than RLIMIT_MEMLOCK it is likely to make all tests fail in a variety of obscure ways (most of which can't be caught in any useful way.) Similarly if the getpagesize returns 0 I hate to think what would happen... it just wouldn't work. Otherwise the only thing I can think of would be if there is threaded tests and the ->store happens after the ->get.. shouldn't happen because I explicitly set "seq: t/*.t" which according to my reading of the docs will force the testers to test in a single thread/sequence order. Thoughts are appreciated. Regards, -- Michelle Sullivan http://www.mhix.org/
Download (untitled) / with headers
text/plain 2.7k
On 2019-02-09 11:38:09, michelle@sorbs.net wrote: Show quoted text
> Slaven_Rezic via RT wrote:
> > Sat Feb 09 11:21:49 2019: Request 128467 was acted upon. > > Transaction: Ticket created by SREZIC > > Queue: Locked-Storage > > Subject: t/03-store-get.t fails on most systems (1.07) > > Broken in: (no value) > > Severity: (no value) > > Owner: Nobody > > Requestors: SREZIC@cpan.org > > Status: new > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=128467 > > > > > > > On most of my smokers t/03-store-get.t fails: > > > > ... > > # Failed test 'Retrieve Data' > > # at t/03-store-get.t line 15. > > # got: undef > > # expected: 'Hello World!' > > # Looks like you failed 1 test of 2. > > t/03-store-get.t .. > > Dubious, test returned 1 (wstat 256, 0x100) > > Failed 1/2 subtests > > ... > > > > There are a couple of systems where this test is passing, however I > > don't see a os/perlversion pattern.
> > Hmm.. you'd need to check the memory (possibly using $ls->dump) to see > if the store actually put the data in the memory
I did so on one system (ubuntu 18.04, perl 5.29.7) and got 0 48 65 6c 6c 6f 20 57 6f 72 6c 64 21 00 00 00 00 Hello Wo rld!.... 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ (more zeroes following) 4080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ Still it failed: # Failed test 'Retrieve Data' # at t/03-store-get.t line 16. # got: undef # expected: 'Hello World!' # Looks like you failed 1 test of 2. t/03-store-get.t .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/2 subtests Show quoted text
> - I think I need to > really pull my finger out and check for OS errors (I wrote it as > something quick for a project I'm working on which it just works on) > it's possible that the os/perlversion pattern might present itself > when > you check the default page size vs RLIMIT_MEMLOCK for a user.... > because > of the fact the fact mlock() will only lock a page (multiples thereof) > I > don't set what bytes are requested instead allocating a full page > (multiple therefore based on the ->new parameter).. if the default > pagesize is larger than RLIMIT_MEMLOCK it is likely to make all tests > fail in a variety of obscure ways (most of which can't be caught in > any > useful way.) Similarly if the getpagesize returns 0 I hate to think > what > would happen... it just wouldn't work. Otherwise the only thing I can > think of would be if there is threaded tests and the ->store happens > after the ->get.. shouldn't happen because I explicitly set "seq: > t/*.t" > which according to my reading of the docs will force the testers to > test > in a single thread/sequence order.
Actually this is not a problem on my smokers --- I always test without -j and shuffle.
Subject: Re: [rt.cpan.org #128467] t/03-store-get.t fails on most systems (1.07)
Date: Sun, 10 Feb 2019 03:47:59 +1100
To: bug-Locked-Storage [...] rt.cpan.org
From: Michelle Sullivan <michelle [...] sorbs.net>
Download (untitled) / with headers
text/plain 3.3k
That’s even weirder.. the data is clearly in the memory region.. the ->get() should just return it.... unless the count is wrong (count would have to be zero.. but even then that should (if I understand correctly) return “” instead of undef. In bed now so will take a look later when I get up. Thanks again. Michelle Sullivan http://www.mhix.org/ Sent from my iPad Show quoted text
> On 10 Feb 2019, at 03:43, Slaven_Rezic via RT <bug-Locked-Storage@rt.cpan.org> wrote: > > Queue: Locked-Storage > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=128467 > >
>> On 2019-02-09 11:38:09, michelle@sorbs.net wrote: >> Slaven_Rezic via RT wrote:
>>> Sat Feb 09 11:21:49 2019: Request 128467 was acted upon. >>> Transaction: Ticket created by SREZIC >>> Queue: Locked-Storage >>> Subject: t/03-store-get.t fails on most systems (1.07) >>> Broken in: (no value) >>> Severity: (no value) >>> Owner: Nobody >>> Requestors: SREZIC@cpan.org >>> Status: new >>> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=128467 > >>> >>> >>> On most of my smokers t/03-store-get.t fails: >>> >>> ... >>> # Failed test 'Retrieve Data' >>> # at t/03-store-get.t line 15. >>> # got: undef >>> # expected: 'Hello World!' >>> # Looks like you failed 1 test of 2. >>> t/03-store-get.t .. >>> Dubious, test returned 1 (wstat 256, 0x100) >>> Failed 1/2 subtests >>> ... >>> >>> There are a couple of systems where this test is passing, however I >>> don't see a os/perlversion pattern.
>> >> Hmm.. you'd need to check the memory (possibly using $ls->dump) to see >> if the store actually put the data in the memory
> > I did so on one system (ubuntu 18.04, perl 5.29.7) and got > > 0 48 65 6c 6c 6f 20 57 6f 72 6c 64 21 00 00 00 00 Hello Wo rld!.... > 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ > (more zeroes following) > 4080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ > > Still it failed: > > # Failed test 'Retrieve Data' > # at t/03-store-get.t line 16. > # got: undef > # expected: 'Hello World!' > # Looks like you failed 1 test of 2. > t/03-store-get.t .. Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/2 subtests > >
>> - I think I need to >> really pull my finger out and check for OS errors (I wrote it as >> something quick for a project I'm working on which it just works on) >> it's possible that the os/perlversion pattern might present itself >> when >> you check the default page size vs RLIMIT_MEMLOCK for a user.... >> because >> of the fact the fact mlock() will only lock a page (multiples thereof) >> I >> don't set what bytes are requested instead allocating a full page >> (multiple therefore based on the ->new parameter).. if the default >> pagesize is larger than RLIMIT_MEMLOCK it is likely to make all tests >> fail in a variety of obscure ways (most of which can't be caught in >> any >> useful way.) Similarly if the getpagesize returns 0 I hate to think >> what >> would happen... it just wouldn't work. Otherwise the only thing I can >> think of would be if there is threaded tests and the ->store happens >> after the ->get.. shouldn't happen because I explicitly set "seq: >> t/*.t" >> which according to my reading of the docs will force the testers to >> test >> in a single thread/sequence order.
> > Actually this is not a problem on my smokers --- I always test without -j and shuffle. > >
Subject: Re: [rt.cpan.org #128467] t/03-store-get.t fails on most systems (1.07)
Date: Sun, 10 Feb 2019 10:51:49 +1100
To: bug-Locked-Storage [...] rt.cpan.org
From: Michelle Sullivan <michelle [...] sorbs.net>
Download (untitled) / with headers
text/plain 3.8k
And now I’m up, systems that we’re passing are now failing... seems each time it’s tested different results are possible. Michelle Sullivan http://www.mhix.org/ Sent from my iPad Show quoted text
> On 10 Feb 2019, at 03:48, Michelle Sullivan via RT <bug-Locked-Storage@rt.cpan.org> wrote: > > Queue: Locked-Storage > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=128467 > > > That’s even weirder.. the data is clearly in the memory region.. the ->get() should just return it.... unless the count is wrong (count would have to be zero.. but even then that should (if I understand correctly) return “” instead of undef. > > In bed now so will take a look later when I get up. > > Thanks again. > > Michelle Sullivan > http://www.mhix.org/ > Sent from my iPad >
>> On 10 Feb 2019, at 03:43, Slaven_Rezic via RT <bug-Locked-Storage@rt.cpan.org> wrote: >> >> Queue: Locked-Storage >> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=128467 > >>
>>>> On 2019-02-09 11:38:09, michelle@sorbs.net wrote: >>>> Slaven_Rezic via RT wrote: >>>> Sat Feb 09 11:21:49 2019: Request 128467 was acted upon. >>>> Transaction: Ticket created by SREZIC >>>> Queue: Locked-Storage >>>> Subject: t/03-store-get.t fails on most systems (1.07) >>>> Broken in: (no value) >>>> Severity: (no value) >>>> Owner: Nobody >>>> Requestors: SREZIC@cpan.org >>>> Status: new >>>> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=128467 > >>>> >>>> >>>> On most of my smokers t/03-store-get.t fails: >>>> >>>> ... >>>> # Failed test 'Retrieve Data' >>>> # at t/03-store-get.t line 15. >>>> # got: undef >>>> # expected: 'Hello World!' >>>> # Looks like you failed 1 test of 2. >>>> t/03-store-get.t .. >>>> Dubious, test returned 1 (wstat 256, 0x100) >>>> Failed 1/2 subtests >>>> ... >>>> >>>> There are a couple of systems where this test is passing, however I >>>> don't see a os/perlversion pattern.
>>> >>> Hmm.. you'd need to check the memory (possibly using $ls->dump) to see >>> if the store actually put the data in the memory
>> >> I did so on one system (ubuntu 18.04, perl 5.29.7) and got >> >> 0 48 65 6c 6c 6f 20 57 6f 72 6c 64 21 00 00 00 00 Hello Wo rld!.... >> 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ >> (more zeroes following) >> 4080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ >> >> Still it failed: >> >> # Failed test 'Retrieve Data' >> # at t/03-store-get.t line 16. >> # got: undef >> # expected: 'Hello World!' >> # Looks like you failed 1 test of 2. >> t/03-store-get.t .. Dubious, test returned 1 (wstat 256, 0x100) >> Failed 1/2 subtests >> >>
>>> - I think I need to >>> really pull my finger out and check for OS errors (I wrote it as >>> something quick for a project I'm working on which it just works on) >>> it's possible that the os/perlversion pattern might present itself >>> when >>> you check the default page size vs RLIMIT_MEMLOCK for a user.... >>> because >>> of the fact the fact mlock() will only lock a page (multiples thereof) >>> I >>> don't set what bytes are requested instead allocating a full page >>> (multiple therefore based on the ->new parameter).. if the default >>> pagesize is larger than RLIMIT_MEMLOCK it is likely to make all tests >>> fail in a variety of obscure ways (most of which can't be caught in >>> any >>> useful way.) Similarly if the getpagesize returns 0 I hate to think >>> what >>> would happen... it just wouldn't work. Otherwise the only thing I can >>> think of would be if there is threaded tests and the ->store happens >>> after the ->get.. shouldn't happen because I explicitly set "seq: >>> t/*.t" >>> which according to my reading of the docs will force the testers to >>> test >>> in a single thread/sequence order.
>> >> Actually this is not a problem on my smokers --- I always test without -j and shuffle. >> >>
>
Download (untitled) / with headers
text/plain 4.5k
The result from statistical analysis seems to be clear: http://analysis.cpantesters.org/solved?distv=Locked-Storage-1.07 That is, it fails if ExtUtils::ParseXS >= 3.28 is installed. I could verify this on one system (CentOS 7 with system perl (5.16.3)): pass with the preinstalled ExtUtils::ParseXS (3.18), fail with the latest version from CPAN. On 2019-02-09 18:52:06, michelle@sorbs.net wrote: Show quoted text
> And now I’m up, systems that we’re passing are now failing... seems > each time it’s tested different results are possible. > > Michelle Sullivan > http://www.mhix.org/ > Sent from my iPad >
> > On 10 Feb 2019, at 03:48, Michelle Sullivan via RT <bug-Locked- > > Storage@rt.cpan.org> wrote: > > > > Queue: Locked-Storage > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=128467 > > > > > That’s even weirder.. the data is clearly in the memory region.. the > > ->get() should just return it.... unless the count is wrong (count > > would have to be zero.. but even then that should (if I understand > > correctly) return “” instead of undef. > > > > In bed now so will take a look later when I get up. > > > > Thanks again. > > > > Michelle Sullivan > > http://www.mhix.org/ > > Sent from my iPad > >
> >> On 10 Feb 2019, at 03:43, Slaven_Rezic via RT <bug-Locked- > >> Storage@rt.cpan.org> wrote: > >> > >> Queue: Locked-Storage > >> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=128467 > > >>
> >>>> On 2019-02-09 11:38:09, michelle@sorbs.net wrote: > >>>> Slaven_Rezic via RT wrote: > >>>> Sat Feb 09 11:21:49 2019: Request 128467 was acted upon. > >>>> Transaction: Ticket created by SREZIC > >>>> Queue: Locked-Storage > >>>> Subject: t/03-store-get.t fails on most systems (1.07) > >>>> Broken in: (no value) > >>>> Severity: (no value) > >>>> Owner: Nobody > >>>> Requestors: SREZIC@cpan.org > >>>> Status: new > >>>> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=128467 > > >>>> > >>>> > >>>> On most of my smokers t/03-store-get.t fails: > >>>> > >>>> ... > >>>> # Failed test 'Retrieve Data' > >>>> # at t/03-store-get.t line 15. > >>>> # got: undef > >>>> # expected: 'Hello World!' > >>>> # Looks like you failed 1 test of 2. > >>>> t/03-store-get.t .. > >>>> Dubious, test returned 1 (wstat 256, 0x100) > >>>> Failed 1/2 subtests > >>>> ... > >>>> > >>>> There are a couple of systems where this test is passing, however > >>>> I > >>>> don't see a os/perlversion pattern.
> >>> > >>> Hmm.. you'd need to check the memory (possibly using $ls->dump) to > >>> see > >>> if the store actually put the data in the memory
> >> > >> I did so on one system (ubuntu 18.04, perl 5.29.7) and got > >> > >> 0 48 65 6c 6c 6f 20 57 6f 72 6c 64 21 00 00 00 00 Hello Wo > >> rld!.... > >> 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ > >> ........ > >> (more zeroes following) > >> 4080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ > >> ........ > >> > >> Still it failed: > >> > >> # Failed test 'Retrieve Data' > >> # at t/03-store-get.t line 16. > >> # got: undef > >> # expected: 'Hello World!' > >> # Looks like you failed 1 test of 2. > >> t/03-store-get.t .. Dubious, test returned 1 (wstat 256, 0x100) > >> Failed 1/2 subtests > >> > >>
> >>> - I think I need to > >>> really pull my finger out and check for OS errors (I wrote it as > >>> something quick for a project I'm working on which it just works > >>> on) > >>> it's possible that the os/perlversion pattern might present itself > >>> when > >>> you check the default page size vs RLIMIT_MEMLOCK for a user.... > >>> because > >>> of the fact the fact mlock() will only lock a page (multiples > >>> thereof) > >>> I > >>> don't set what bytes are requested instead allocating a full page > >>> (multiple therefore based on the ->new parameter).. if the default > >>> pagesize is larger than RLIMIT_MEMLOCK it is likely to make all > >>> tests > >>> fail in a variety of obscure ways (most of which can't be caught in > >>> any > >>> useful way.) Similarly if the getpagesize returns 0 I hate to think > >>> what > >>> would happen... it just wouldn't work. Otherwise the only thing I > >>> can > >>> think of would be if there is threaded tests and the ->store > >>> happens > >>> after the ->get.. shouldn't happen because I explicitly set "seq: > >>> t/*.t" > >>> which according to my reading of the docs will force the testers to > >>> test > >>> in a single thread/sequence order.
> >> > >> Actually this is not a problem on my smokers --- I always test > >> without -j and shuffle. > >> > >>
> >
Subject: Re: [rt.cpan.org #128467] t/03-store-get.t fails on most systems (1.07)
Date: Sun, 10 Feb 2019 22:39:26 +1100
To: bug-Locked-Storage [...] rt.cpan.org
From: Michelle Sullivan <michelle [...] sorbs.net>
Download (untitled) / with headers
text/plain 4.8k
That would make sense... have 3.16 here and can’t diagnose anything as it all passes. Michelle Sullivan http://www.mhix.org/ Sent from my iPad Show quoted text
> On 10 Feb 2019, at 20:58, Slaven_Rezic via RT <bug-Locked-Storage@rt.cpan.org> wrote: > > Queue: Locked-Storage > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=128467 > > > The result from statistical analysis seems to be clear: http://analysis.cpantesters.org/solved?distv=Locked-Storage-1.07 > That is, it fails if ExtUtils::ParseXS >= 3.28 is installed. > > I could verify this on one system (CentOS 7 with system perl (5.16.3)): pass with the preinstalled ExtUtils::ParseXS (3.18), fail with the latest version from CPAN. >
>> On 2019-02-09 18:52:06, michelle@sorbs.net wrote: >> And now I’m up, systems that we’re passing are now failing... seems >> each time it’s tested different results are possible. >> >> Michelle Sullivan >> http://www.mhix.org/ >> Sent from my iPad >>
>>> On 10 Feb 2019, at 03:48, Michelle Sullivan via RT <bug-Locked- >>> Storage@rt.cpan.org> wrote: >>> >>> Queue: Locked-Storage >>> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=128467 > >>> >>> That’s even weirder.. the data is clearly in the memory region.. the >>> ->get() should just return it.... unless the count is wrong (count >>> would have to be zero.. but even then that should (if I understand >>> correctly) return “” instead of undef. >>> >>> In bed now so will take a look later when I get up. >>> >>> Thanks again. >>> >>> Michelle Sullivan >>> http://www.mhix.org/ >>> Sent from my iPad >>>
>>>> On 10 Feb 2019, at 03:43, Slaven_Rezic via RT <bug-Locked- >>>> Storage@rt.cpan.org> wrote: >>>> >>>> Queue: Locked-Storage >>>> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=128467 > >>>>
>>>>>> On 2019-02-09 11:38:09, michelle@sorbs.net wrote: >>>>>> Slaven_Rezic via RT wrote: >>>>>> Sat Feb 09 11:21:49 2019: Request 128467 was acted upon. >>>>>> Transaction: Ticket created by SREZIC >>>>>> Queue: Locked-Storage >>>>>> Subject: t/03-store-get.t fails on most systems (1.07) >>>>>> Broken in: (no value) >>>>>> Severity: (no value) >>>>>> Owner: Nobody >>>>>> Requestors: SREZIC@cpan.org >>>>>> Status: new >>>>>> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=128467 > >>>>>> >>>>>> >>>>>> On most of my smokers t/03-store-get.t fails: >>>>>> >>>>>> ... >>>>>> # Failed test 'Retrieve Data' >>>>>> # at t/03-store-get.t line 15. >>>>>> # got: undef >>>>>> # expected: 'Hello World!' >>>>>> # Looks like you failed 1 test of 2. >>>>>> t/03-store-get.t .. >>>>>> Dubious, test returned 1 (wstat 256, 0x100) >>>>>> Failed 1/2 subtests >>>>>> ... >>>>>> >>>>>> There are a couple of systems where this test is passing, however >>>>>> I >>>>>> don't see a os/perlversion pattern.
>>>>> >>>>> Hmm.. you'd need to check the memory (possibly using $ls->dump) to >>>>> see >>>>> if the store actually put the data in the memory
>>>> >>>> I did so on one system (ubuntu 18.04, perl 5.29.7) and got >>>> >>>> 0 48 65 6c 6c 6f 20 57 6f 72 6c 64 21 00 00 00 00 Hello Wo >>>> rld!.... >>>> 16 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ >>>> ........ >>>> (more zeroes following) >>>> 4080 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ >>>> ........ >>>> >>>> Still it failed: >>>> >>>> # Failed test 'Retrieve Data' >>>> # at t/03-store-get.t line 16. >>>> # got: undef >>>> # expected: 'Hello World!' >>>> # Looks like you failed 1 test of 2. >>>> t/03-store-get.t .. Dubious, test returned 1 (wstat 256, 0x100) >>>> Failed 1/2 subtests >>>> >>>>
>>>>> - I think I need to >>>>> really pull my finger out and check for OS errors (I wrote it as >>>>> something quick for a project I'm working on which it just works >>>>> on) >>>>> it's possible that the os/perlversion pattern might present itself >>>>> when >>>>> you check the default page size vs RLIMIT_MEMLOCK for a user.... >>>>> because >>>>> of the fact the fact mlock() will only lock a page (multiples >>>>> thereof) >>>>> I >>>>> don't set what bytes are requested instead allocating a full page >>>>> (multiple therefore based on the ->new parameter).. if the default >>>>> pagesize is larger than RLIMIT_MEMLOCK it is likely to make all >>>>> tests >>>>> fail in a variety of obscure ways (most of which can't be caught in >>>>> any >>>>> useful way.) Similarly if the getpagesize returns 0 I hate to think >>>>> what >>>>> would happen... it just wouldn't work. Otherwise the only thing I >>>>> can >>>>> think of would be if there is threaded tests and the ->store >>>>> happens >>>>> after the ->get.. shouldn't happen because I explicitly set "seq: >>>>> t/*.t" >>>>> which according to my reading of the docs will force the testers to >>>>> test >>>>> in a single thread/sequence order.
>>>> >>>> Actually this is not a problem on my smokers --- I always test >>>> without -j and shuffle. >>>> >>>>
>>>
> > >
Subject: Re: [rt.cpan.org #128467] t/03-store-get.t fails on most systems (1.07)
Date: Sun, 10 Feb 2019 22:47:51 +1100
To: bug-Locked-Storage [...] rt.cpan.org
From: Michelle Sullivan <michelle [...] sorbs.net>
Download (untitled) / with headers
text/plain 355b
Michelle Sullivan via RT wrote: Show quoted text
> Queue: Locked-Storage > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=128467 > > > That would make sense... have 3.16 here and can’t diagnose anything as it all passes. >
Ok just put 3.35 in here and can reproduce.. will work on a fix. Thanks, Michelle -- Michelle Sullivan http://www.mhix.org/
Subject: Re: [rt.cpan.org #128467] t/03-store-get.t fails on most systems (1.07)
Date: Mon, 11 Feb 2019 00:38:42 +1100
To: bug-Locked-Storage [...] rt.cpan.org
From: Michelle Sullivan <michelle [...] sorbs.net>
Download (untitled) / with headers
text/plain 552b
Michelle Sullivan via RT wrote: Show quoted text
> Queue: Locked-Storage > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=128467 > > > Michelle Sullivan via RT wrote:
>> Queue: Locked-Storage >> Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=128467 > >> >> That would make sense... have 3.16 here and can’t diagnose anything as it all passes. >>
> Ok just put 3.35 in here and can reproduce.. will work on a fix. > > Thanks, > > Michelle >
Ok new version up - that should be better. -- Michelle Sullivan http://www.mhix.org/
Fixed most tests in 1.10 - those that fail now are segfaulting probably due to localised policy.


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

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.