t/gh29-segv.t fails on some systems
eserte opened this issue · comments
The following test failure seems to happen on some (older) systems (freebsd 9, freebsd 9, debian wheezy, possibly on debian jessie):
t/gh29-segv.t .............
All 2 subtests passed
...
Test Summary Report
-------------------
t/gh29-segv.t (Wstat: 0 Tests: 2 Failed: 0)
Parse errors: Tests out of sequence. Found (2) but expected (1)
Tests out of sequence. Found (1) but expected (2)
Correction: on freebsd 9 it's something different:
# Failed test 'use re::engine::PCRE2;'
# at t/00-compile.t line 4.
# Tried to use 're::engine::PCRE2'.
# Error: Can't load '/usr/home/cpansand/.cpan/build/2019040811/re-engine-PCRE2-0.15-2/blib/arch/auto/re/engine/PCRE2/PCRE2.so' for module re::engine::PCRE2: /usr/home/cpansand/.cpan/build/2019040811/re-engine-PCRE2-0.15-2/blib/arch/auto/re/engine/PCRE2/PCRE2.so: Undefined symbol "pcre2_set_depth_limit_8" at /usr/perl5.16.3t/lib/5.16.3/amd64-freebsd-thread-multi/DynaLoader.pm line 190.
# at t/00-compile.t line 4.
Yes, the fork test is pretty unstable, as slow systems will be too slow to fork. maybe skip the unforked ok.
the libpcre2 library problem needs to be fixed with Devel::CheckLib somehow. they changed the API.
Ah, thanks for the waitpid(). I was too lazy.
I can see you ignore $?. That means you do not catch a case when the child process crashes. I know a faulty PCRE2 crashes in the parent, but still I believe the test could cover it. If you don't care about the child, than it make more sense remove the print from child as it were irrelevant.
On darwin $? was 11, that's why. I still have to investigate why, but I am a bit too busy the next 2 weeks.