libipc-shareable-perl: autopkgtest regression on armhf and i386

[gregoa]

We have the following bug reported to the Debian package of
IPC-Shareable, c.f. https://bugs.debian.org/997829

It doesn't seem to be a bug in the packaging, so you may want to take
a look. Thanks!

Summary: t/65-seg_size.t fails on 32bit hosts (i386 and armhf architectures)

#   Failed test 'We croak if size is greater than max RAM'
#   at t/65-seg_size.t line 52.
#          got: '1'
#     expected: undef

#   Failed test '...and error is sane'
#   at t/65-seg_size.t line 54.
#                   ''
#     doesn't match '(?^:Cannot allocate memory|Out of memory|Invalid argument)'
# Looks like you failed 2 tests of 6.
t/65-seg_size.t ...................... 
ok 1 - size larger than MAX croaks ok
ok 2 - ...and error is sane
not ok 3 - We croak if size is greater than max RAM
not ok 4 - ...and error is sane
ok 5 - size param is the same as the segment size
ok 6 - actual size in bytes ok if sending in custom size
1..6
Dubious, test returned 2 (wstat 512, 0x200)
Failed 2/6 subtests 
..
Test Summary Report
-------------------
t/65-seg_size.t                    (Wstat: 512 Tests: 6 Failed: 2)
  Failed tests:  3-4
  Non-zero exit status: 2
Files=38, Tests=411, 12 wallclock secs ( 0.14 usr  0.02 sys +  5.26 cusr  1.88 csys =  7.30 CPU)
Result: FAIL

Thanks for considering,
gregor herrmann,
Debian Perl Group

[gregoa]

When setting IPC_MEM the expected error occurs (on i386, aka x86_32), but that makes the test fail differently (as it aborts prematurely):

Out of memory!
# Tests were run but no plan was declared and done_testing() was not seen.
# Looks like your test exited with 1 just after 2.
t/65-seg_size.t ...................... 
ok 1 - size larger than MAX croaks ok
ok 2 - ...and error is sane
Dubious, test returned 1 (wstat 256, 0x100)
All 2 subtests passed 
…
Test Summary Report
-------------------
t/65-seg_size.t                    (Wstat: 256 Tests: 2 Failed: 0)
  Non-zero exit status: 1
  Parse errors: No plan found in TAP output
Files=38, Tests=409, 11 wallclock secs ( 0.12 usr  0.02 sys +  4.22 cusr  1.70 csys =  6.06 CPU)
Result: FAIL

On amd64 (aka x86_64) the test just passes with and without IPC_MEM.

[gregoa]

With some debugging statements:

lib/IPC/Shareable/SharedMem.pm
    31      my $id = shmget($key, $size, $flags);

On amd64 $id is undef, as expected, but contains a value on i386.

Cheers,
gregor

[gregoa]

Analysis from @ntyni in https://bugs.debian.org/997829:

It boils down to

  perl -e 'shmget(0, 999999999999, 0666) or die'

which dies on amd64 but not in i386.

Looking further:

  # strace -e shmget perl -we 'shmget(0, 999999999999, 0666) or die'
  shmget(IPC_PRIVATE, 3567587327, 0666)   = 5177377
  +++ exited with 0 +++

Given 999999999999 % 2^32 == 3567587327 it's pretty clear that the
requested size does not fit into 32 bits (shmget(2) takes a size_t)
so just its lower bits get passed in. Not sure if perl should protest
somehow there.

Anyway, seems like the test could just be skipped on 32-bit or something.

[gregoa]

I'm afraid this bug is not fixed yet; with 1.09 we still see t/65-seg_size.t failing on i386 and armhf (with CI_TESTING set):

https://ci.debian.net/data/autopkgtest/testing/i386/libi/libipc-shareable-perl/19804426/log.gz
https://ci.debian.net/data/autopkgtest/testing/armhf/libi/libipc-shareable-perl/19804250/log.gz

[ntyni]

On Mon, Mar 07, 2022 at 07:39:29AM -0800, gregor herrmann wrote: I'm afraid this bug is not fixed yet; with 1.09 we still see `t/65-seg_size.t` failing on i386 and armhf (with `CI_TESTING` set): https://ci.debian.net/data/autopkgtest/testing/i386/libi/libipc-shareable-perl/19804426/log.gz https://ci.debian.net/data/autopkgtest/testing/armhf/libi/libipc-shareable-perl/19804250/log.gz

Yeah, I commented on the commit but I guess it was too late. if ($Config{ivsize} < 8) { plan skip_all => "This test script can't be run on a perl < 64-bit"; } I'm afraid checking ivsize is not enough. We're configuring perl with -Duse64bitint even on 32-bit architectures. So Perl integers are 64-bit (ivsize==8) even though size_t (which is what shmget(2) ultimately takes) is 32-bit. I think that checking for both ivsize and sizesize would work. -- Niko Tyni ***@***.***