Bug #128465 for Locked-Storage: 02-lockall.t fails

Sat Feb 09 10:32:59 2019 SREZIC [...] cpan.org - Ticket created

Subject:

02-lockall.t fails

The test suite fails on all of my smokers. I looked with strace into 02-lockall.t (on a debian/jessie machine with perl 5.28.1) and these are probably the interesting lines: ... 25304 16:24:10.058637 fstat(4, {st_mode=S_IFREG|0755, st_size=15720, ...}) = 0 <0.000005> 25304 16:24:10.058654 mmap(NULL, 2107224, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7feffb100000 <0.000008> 25304 16:24:10.058673 mprotect(0x7feffb103000, 2093056, PROT_NONE) = 0 <0.000008> 25304 16:24:10.058690 mmap(0x7feffb302000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x2000) = 0x7feffb302000 <0.000007> 25304 16:24:10.058711 close(4) = 0 <0.000004> 25304 16:24:10.058823 mlock(0x2d85e30, 4096) = 0 <0.000046> 25304 16:24:10.058887 mlockall(MCL_CURRENT|MCL_FUTURE) = -1 ENOMEM (Cannot allocate memory) <0.000005> 25304 16:24:10.059097 write(5, "not ok 1 - mlockall() call\n", 27) = 27 <0.000013> 25304 16:24:10.059356 write(6, "# Failed test 'mlockall() call'\n# at t/02-lockall.t line 14.\n", 65) = 65 <0.000055> ... So mlockall() fails with ENOMEM. According to the mlockall manpage this seems to happen due to the RLIMIT_MEMLOCK resource limit. limit reports the following: memorylocked 64kB The manpage also says that this limit does not apply if the "process is privileged", and indeed, this test passes if run under root.

Sat Feb 09 10:44:24 2019 SREZIC [...] cpan.org - Correspondence added

On 2019-02-09 10:32:59, SREZIC wrote: Show quoted text

> The test suite fails on all of my smokers. I looked with strace into > 02-lockall.t (on a debian/jessie machine with perl 5.28.1) and these > are probably the interesting lines: > > ... > 25304 16:24:10.058637 fstat(4, {st_mode=S_IFREG|0755, st_size=15720, > ...}) = 0 <0.000005> > 25304 16:24:10.058654 mmap(NULL, 2107224, PROT_READ|PROT_EXEC, > MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7feffb100000 <0.000008> > 25304 16:24:10.058673 mprotect(0x7feffb103000, 2093056, PROT_NONE) = 0 > <0.000008> > 25304 16:24:10.058690 mmap(0x7feffb302000, 4096, PROT_READ|PROT_WRITE, > MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x2000) = 0x7feffb302000 > <0.000007> > 25304 16:24:10.058711 close(4) = 0 <0.000004> > 25304 16:24:10.058823 mlock(0x2d85e30, 4096) = 0 <0.000046> > 25304 16:24:10.058887 mlockall(MCL_CURRENT|MCL_FUTURE) = -1 ENOMEM > (Cannot allocate memory) <0.000005> > 25304 16:24:10.059097 write(5, "not ok 1 - mlockall() call\n", 27) = > 27 <0.000013> > 25304 16:24:10.059356 write(6, "# Failed test 'mlockall() call'\n# > at t/02-lockall.t line 14.\n", 65) = 65 <0.000055> > ... > > So mlockall() fails with ENOMEM. According to the mlockall manpage > this seems to happen due to the RLIMIT_MEMLOCK resource limit. limit > reports the following: > > memorylocked 64kB > > The manpage also says that this limit does not apply if the "process > is privileged", and indeed, this test passes if run under root.

I checked the memorylocked settings on my smokers: debian 10: 64MB ubuntu 18.04 + fedora 28: 16MB ubuntu 16.04: 64kB debian 7, 8, 9: 64kB centos 6, 7: 64kB freebsd 9, 10, 11, 12, 13: 64kB Probably these are default settings, at least I am not aware that I changed this limit.

Sat Feb 09 11:05:06 2019 cpan [...] sorbs.net - Correspondence added

On Sat Feb 09 10:32:59 2019, SREZIC wrote: Show quoted text

> The test suite fails on all of my smokers. I looked with strace into > 02-lockall.t (on a debian/jessie machine with perl 5.28.1) and these > are probably the interesting lines:

Thanks for the headsup, updated the tests in 1.07 to check for user vs root and not fail if running as a user and calling lockall()... Updated the docs noting the issue in the warnings crediting you with the headsup. Many thanks. Regards, Michelle

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

Sat Feb 09 11:05:07 2019 cpan [...] sorbs.net - Status changed from 'open' to 'patched'

Sat Feb 09 11:05:14 2019 cpan [...] sorbs.net - Taken

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

On 2019-02-09 11:05:06, SORBS wrote: Show quoted text

> On Sat Feb 09 10:32:59 2019, SREZIC wrote:

> > The test suite fails on all of my smokers. I looked with strace into > > 02-lockall.t (on a debian/jessie machine with perl 5.28.1) and these > > are probably the interesting lines:

> > Thanks for the headsup, updated the tests in 1.07 to check for user vs > root and not fail if running as a user and calling lockall()... > Updated the docs noting the issue in the warnings crediting you with > the headsup.

The skip seems to work, at least I don't see this test file failing anymore --- still on most of my smokers the test suite fails, but that's another issue.

Sat Feb 09 11:16:44 2019 SREZIC [...] cpan.org - Status changed from 'patched' to 'resolved'

Sat Feb 09 11:24:24 2019 cpan [...] sorbs.net - Correspondence added

On Sat Feb 09 11:16:43 2019, SREZIC wrote: Show quoted text

> The skip seems to work, at least I don't see this test file failing > anymore --- still on most of my smokers the test suite fails, but > that's another issue.

How so (I see no tests on cpan testers yet) ...? trying to get these tests fixed and as this is my first xs module I seem to be having lots more issues than I should :/

Sat Feb 09 11:39:14 2019 SREZIC [...] cpan.org - Correspondence added

On 2019-02-09 11:24:24, SORBS wrote: Show quoted text

> On Sat Feb 09 11:16:43 2019, SREZIC wrote: >

> > The skip seems to work, at least I don't see this test file failing > > anymore --- still on most of my smokers the test suite fails, but > > that's another issue.

> > How so (I see no tests on cpan testers yet) ...?

I look into every fail report before sending it to cpan testers, so I usually know it quite early... Show quoted text

> trying to get these > tests fixed and as this is my first xs module I seem to be having lots > more issues than I should :/

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

Subject:	Re: [rt.cpan.org #128465] 02-lockall.t fails
Date:	Sun, 10 Feb 2019 03:43:03 +1100
To:	bug-Locked-Storage [...] rt.cpan.org
From:	Michelle Sullivan <michelle [...] sorbs.net>

No I meant how is it failing not how are you seeing.. :) got your second email crossed in lag with my reply so it was answered anyhow... :) Michelle Sullivan http://www.mhix.org/ Sent from my iPad Show quoted text

> On 10 Feb 2019, at 03:39, Slaven_Rezic via RT <bug-Locked-Storage@rt.cpan.org> wrote: > > Queue: Locked-Storage > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=128465 > >

>> On 2019-02-09 11:24:24, SORBS wrote:

>>> On Sat Feb 09 11:16:43 2019, SREZIC wrote: >>> >>> The skip seems to work, at least I don't see this test file failing >>> anymore --- still on most of my smokers the test suite fails, but >>> that's another issue.

>> >> How so (I see no tests on cpan testers yet) ...?

> > I look into every fail report before sending it to cpan testers, so I usually know it quite early... >

>> trying to get these >> tests fixed and as this is my first xs module I seem to be having lots >> more issues than I should :/

> > >

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

Subject:	Re: [rt.cpan.org #128465] 02-lockall.t fails
Date:	Sun, 10 Feb 2019 02:59:17 +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 10:32:59 2019: Request 128465 was acted upon. > Transaction: Ticket created by SREZIC > Queue: Locked-Storage > Subject: 02-lockall.t fails > Broken in: 1.05 > Severity: (no value) > Owner: Nobody > Requestors: SREZIC@cpan.org > Status: new > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=128465 > > > > The test suite fails on all of my smokers. I looked with strace into 02-lockall.t (on a debian/jessie machine with perl 5.28.1) and these are probably the interesting lines: > > ... > 25304 16:24:10.058637 fstat(4, {st_mode=S_IFREG|0755, st_size=15720, ...}) = 0 <0.000005> > 25304 16:24:10.058654 mmap(NULL, 2107224, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 4, 0) = 0x7feffb100000 <0.000008> > 25304 16:24:10.058673 mprotect(0x7feffb103000, 2093056, PROT_NONE) = 0 <0.000008> > 25304 16:24:10.058690 mmap(0x7feffb302000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 4, 0x2000) = 0x7feffb302000 <0.000007> > 25304 16:24:10.058711 close(4) = 0 <0.000004> > 25304 16:24:10.058823 mlock(0x2d85e30, 4096) = 0 <0.000046> > 25304 16:24:10.058887 mlockall(MCL_CURRENT|MCL_FUTURE) = -1 ENOMEM (Cannot allocate memory) <0.000005> > 25304 16:24:10.059097 write(5, "not ok 1 - mlockall() call\n", 27) = 27 <0.000013> > 25304 16:24:10.059356 write(6, "# Failed test 'mlockall() call'\n# at t/02-lockall.t line 14.\n", 65) = 65 <0.000055> > ... > > So mlockall() fails with ENOMEM. According to the mlockall manpage this seems to happen due to the RLIMIT_MEMLOCK resource limit. limit reports the following: > > memorylocked 64kB > > The manpage also says that this limit does not apply if the "process is privileged", and indeed, this test passes if run under root. > >

Thanks for the headsup - 1.07 uploaded where the tests specifically test for running as a user and will not fail if the lockall() call fails. Regards, -- Michelle Sullivan http://www.mhix.org/