Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

t/gh29-segv.t fails on some systems #34

Open
eserte opened this issue Apr 9, 2019 · 5 comments

Comments

Projects
None yet
3 participants
@eserte
Copy link

commented Apr 9, 2019

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)
@eserte

This comment has been minimized.

Copy link
Author

commented Apr 9, 2019

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

This comment has been minimized.

Copy link
Owner

commented Apr 9, 2019

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.

@rurban rurban added the bug label Apr 12, 2019

ppisar added a commit to ppisar/re-engine-PCRE2 that referenced this issue May 15, 2019

Avoid a race in t/gh29-segv.t
If the a parent process was too slow, a child process could print
"ok 2" before the parent printed "ok 1". That resulted into unordered
tests and was reported as an error.

This patch eliminites the race by synchronizing on the child
termination by calling waitpid(). Nevertheless it's necessary to
collect child's statuses to prevent from creating zombies.

rurban#34
@rurban

This comment has been minimized.

Copy link
Owner

commented May 15, 2019

Ah, thanks for the waitpid(). I was too lazy.

rurban added a commit that referenced this issue May 15, 2019

Avoid a race in t/gh29-segv.t
If the a parent process was too slow, a child process could print
"ok 2" before the parent printed "ok 1". That resulted into unordered
tests and was reported as an error.

This patch eliminites the race by synchronizing on the child
termination by calling waitpid(). Nevertheless it's necessary to
collect child's statuses to prevent from creating zombies.

#34
@ppisar

This comment has been minimized.

Copy link
Contributor

commented May 16, 2019

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.

@rurban

This comment has been minimized.

Copy link
Owner

commented May 16, 2019

On darwin $? was 11, that's why. I still have to investigate why, but I am a bit too busy the next 2 weeks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.