stevieb9 / ipc-shareable

Share Perl variables across processes and scripts
GNU General Public License v2.0
3 stars 2 forks source link

t/35-clean.t hangs/fails #16

Closed openstrike closed 2 years ago

openstrike commented 2 years ago

I am encountering problems in t/35-clean.t on one machine but it passes fine on others of similar spec and O/S.

To reproduce either:

  1. Run cpanm --sudo IPC::Shareable which will eventually fail after a long time with -> FAIL Timed out (> 1800s). Use --verbose to retry.

  2. By hand, download the 1.06 tarball, untar, perl Makefile.PL; make; make test which similarly hangs until interrupted or,

  3. Run the test individually with prove -bv t/35-clean.t in which case it fails like this:

    
    ok 1 - We croak if a key is specified, create is not called and no segment exists
    ok 2 - ...and error message is sane
    ok 3 - Default (IPC_PRIVATE) SV set and value is 'foobar'
    ok 4 - Global register has one entry ok
    ok 5 - Process register has one entry ok
    ok 6 - ID 6127621 exists in global register
    ok 7 - ID 6127621 exists in process register
    ok 8 - Default (IPC_PRIVATE) seg id 6127621 removed after remove() ok
    ok 9 - Global register cleaned after remove()
    ok 10 - Process register cleaned after remove()
    ok 11 - SV set and value is 'foobar'
    ok 12 - Global register has one entry ok
    ok 13 - Process register has one entry ok
    ok 14 - ID 6160389 exists in global register
    ok 15 - ID 6160389 exists in process register
    ok 16 - seg id 6160389 removed after remove() ok
    ok 17 - Global register cleaned after remove()
    ok 18 - Process register cleaned after remove()
    ok 19 - SV set and value is 'foobar'
    ok 20 - Global register has one entry ok
    ok 21 - Process register has one entry ok
    ok 22 - ID 6193157 exists in global register
    ok 23 - ID 6193157 exists in process register
    ok 24 - seg id 6193157 removed after clean_up() ok
    ok 25 - Global register cleaned after clean_up()
    ok 26 - Process register cleaned after clean_up()
    ok 27 - SV set and value is 'foobar'
    ok 28 - Global register has one entry ok
    ok 29 - Process register has one entry ok
    ok 30 - ID 6225925 exists in global register
    ok 31 - ID 6225925 exists in process register
    ok 32 - seg id 6225925 removed after clean_up_all() ok
    ok 33 - Global register cleaned after clean_up_all()
    ok 34 - Process register cleaned after clean_up_all()
    ok 35 - SV initialized and set to 'baz' ok
    ok 36 - Shared memory alive ok in child
    ok 37 - after clean_up(), all is well ok in child, we don't clean up what isn't ours
    ok 38 - SV doesn't get wiped if in a different proc w/clean_up()
    ok 39 - ID 4161539 was not cleaned up in the child
    not ok 40 - Global register set before clean_up_all()

Failed test 'Global register set before clean_up_all()'

at t/35-clean.t line 180.

got: '0'

expected: '1'

not ok 41 - Process register set before clean_up_all()

Failed test 'Process register set before clean_up_all()'

at t/35-clean.t line 181.

got: '0'

expected: '1'

ok 42 - Global register cleaned with clean_up_all() ok 43 - Process register cleaned with clean_up_all() 1..43

Looks like you failed 2 tests of 43.

Dubious, test returned 2 (wstat 512, 0x200) Failed 2/43 subtests

Test Summary Report

t/35-clean.t (Wstat: 512 Tests: 43 Failed: 2) Failed tests: 40-41 Non-zero exit status: 2 Files=1, Tests=43, 0 wallclock secs ( 0.03 usr 0.02 sys + 0.11 cusr 0.05 csys = 0.21 CPU) Result: FAIL



This is perl 5, version 22, subversion 2 (v5.22.2) built for x86_64-linux-thread-multi running on Slackware 14.2.

The only relevant difference I can think of between this machine and the others where it passes is that this one has a custom-built kernel; there could well be something in the kernel config causing this but I don't know what that might be. Any ideas welcome.
openstrike commented 2 years ago

The server which was exhibiting this has now been upgraded to Slackware 15 and with this the original need for IPC::Shareable no longer exists, so I'll close this issue. With no other such reports it was likely something peculiar to that one instance anyway.