#282 t/pthreadBarf.t test fails

critical
closed-fixed
John Cerney
core (120)
9
2011-09-04
2011-08-17
Chris Marshall
No

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

Discussion

  • Chris Marshall
    Chris Marshall
    2011-08-17

    Tentatively assigning to John Cerney since it is his test code.

     
  • Chris Marshall
    Chris Marshall
    2011-08-17

    • assigned_to: nobody --> cerney
     
  • Chris Marshall
    Chris Marshall
    2011-08-19

    • priority: 5 --> 9
    • milestone: --> critical
     
  • Chris Marshall
    Chris Marshall
    2011-08-19

    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.

     
  • Chris Marshall
    Chris Marshall
    2011-08-19

    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.

     
  • Chris Marshall
    Chris Marshall
    2011-08-20

    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.

     
  • John Cerney
    John Cerney
    2011-08-21

    • status: open --> open-fixed
     
  • John Cerney
    John Cerney
    2011-08-21

    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.

     
  • Chris Marshall
    Chris Marshall
    2011-08-21

    Fix is in latest CPAN Developers release CHM/PDL-2.4.9_007.tar.gz
    CPAN Testers results look promising so far...

     
  • Chris Marshall
    Chris Marshall
    2011-08-22

    Latest fix appears to be working well. Marking this ticket Pending to
    close in 2 weeks unless further action is required.

     
  • Chris Marshall
    Chris Marshall
    2011-08-22

    • status: open-fixed --> pending-fixed
     
  • Chris Marshall
    Chris Marshall
    2011-08-23

    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?

     
  • Chris Marshall
    Chris Marshall
    2011-08-23

    • status: pending-fixed --> open-fixed
     
  • Chris Marshall
    Chris Marshall
    2011-08-25

    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.

     
  • John Cerney
    John Cerney
    2011-08-25

    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.

     
  • Chris Marshall
    Chris Marshall
    2011-09-04

    • status: open-fixed --> closed-fixed