Menu
▾
▴
#282 t/pthreadBarf.t test fails
The latest PDL-2.4.9_005 release shows test fails for the t/pthreadBarf.t:
http://www.cpantesters.org/cpan/report/b2d56214-c8b0-11e0-8be4-ef3abcd6199c
The fails appear to be due to an incorrect test output. Converting the test
to use the preferred Test::More module features should clean up the logic
and make the test conformant with the make test harness.
(N.B. I'm assuming that the problem is only in the structure of the test
and not a problem with the new better barf functionality and pthreads.)
Need to fix by 2.4.10
Tentatively assigning to John Cerney since it is his test code.
This one bug accounts for 100% of the FAIL reports for PDL-2.4.9_005.
Increasing the Priority and marking critical to resolve before the 2.4.10
release this Fall---sooner would be better.
Additional feedback from a CPAN Tester re-running the specific test by hand:
> On the same machine, same perl and test environment, I ran
> t/pthreadBarf.t and got a segfault. When I ran "make test" the test
> failed with the same failure as in my smoke test. (Same with all the
> other similarly built perls).
>
> If I can check anything else for you, just let me know.
>
>
> [perl514@firenze PDL-2.4.9_005]$ ~/testing/perl-5.14.1/bin/perl5.14.1 -Mblib t/pthreadBarf.t
> 1..2
> Segmentation fault
>
> regards,
> daniël
So it appears that the problem is the dreaded segfault
which makes it impossible to diagnose from test results
alone since perl itself dies. We'll definitely need to
reproduce and debug this. In the meantime, I'll skip the
tests for upcoming CPAN developers releases until I
hear a fix has been made and is ok for general testing.
I've updated t/pthreadBarf.t to use Test::More and allowed
non-pthreads platforms to run the tests as well for a control.
At the least, things should not break if pthreads is not enabled.
Recent changes (between 2.4.9_004 and 2.4.9_005) caused the pthreadBarf.t test case to fail. Moved the dSP; call in pdl_barf_or_warn to fix the problem.
Fix is in latest CPAN Developers release CHM/PDL-2.4.9_007.tar.gz
CPAN Testers results look promising so far...
Latest fix appears to be working well. Marking this ticket Pending to
close in 2 weeks unless further action is required.
Why does moving the dSP from after the if ( pdl_pthread_barf_or_warn...)
call fix things? Rob is hacking in a workaround for MSVC compilers
but it seems like such a fix should not be needed. Any ideas, John?
Maybe the call of pdl_pthread_barf_or_warn() messes up the
perl stack pointer. If so, a dSP before and a dSP after would
give different results.
I think any call to the perl internals from one of the pthreads (i.e. the threads forked off to do processing) can potentially cause a crash. That is probably why the dSP call causes a crash.