Bug #128467 for Locked-Storage: t/03-store-get.t fails on most systems (1.07)

Sat Feb 09 11:21:49 2019 SREZIC [...] cpan.org - Ticket created

Subject:

t/03-store-get.t fails on most systems (1.07)

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.

Sat Feb 09 11:38:09 2019 michelle [...] sorbs.net - Correspondence added

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/

Sat Feb 09 11:38:10 2019 The RT System itself - Status changed from 'new' to 'open'

Sat Feb 09 11:43:37 2019 SREZIC [...] cpan.org - Correspondence added

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.

Sat Feb 09 11:48:12 2019 michelle [...] sorbs.net - Correspondence added

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>

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. > >

Sat Feb 09 18:52:06 2019 michelle [...] sorbs.net - Correspondence added

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>

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. >> >>

Sun Feb 10 04:58:55 2019 SREZIC [...] cpan.org - Correspondence added

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. > >> > >>

> >

Sun Feb 10 06:39:46 2019 michelle [...] sorbs.net - Correspondence added

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>

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. >>>> >>>>

>>>

> > >

Sun Feb 10 06:48:15 2019 michelle [...] sorbs.net - Correspondence added

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>

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/

Sun Feb 10 08:38:56 2019 michelle [...] sorbs.net - Correspondence added

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>

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/

Fri Feb 15 00:42:06 2019 cpan [...] sorbs.net - Taken

Fri Feb 15 00:42:54 2019 cpan [...] sorbs.net - Correspondence added

Fixed most tests in 1.10 - those that fail now are segfaulting probably due to localised policy.

Fri Feb 15 00:42:55 2019 cpan [...] sorbs.net - Status changed from 'open' to 'resolved'