Skip Menu |

This queue is for tickets about the Parallel-SubFork CPAN distribution.

Report information
The Basics
Id: 51465
Status: resolved
Priority: 0/
Queue: Parallel-SubFork

People
Owner: Nobody in particular
Requestors: patrick.schulz [...] globalfoundries.com
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Dependency problem (resolved)
Date: Thu, 12 Nov 2009 11:51:20 +0100
To: bug-Parallel-SubFork [...] rt.cpan.org
From: Patrick Schulz <patrick.schulz [...] globalfoundries.com>
Hello, when I tried to install Parallel-SubFork-0.06 in our perl-5.8.8 installation (x86_64 GNU/Linux) the tests failed like for may other testers. Same happened with perl-5.8.9. When I looked into the code I found that you use Time::HiRes (but it's not mentioned in the doc). After upgrading Time::HiRes from version v1.86 to v1.9719 all tests were passed (on perl-5.8.8 and perl-5.8.9). So it seems to be important to have the right version of Time::HiRes installed. Please state this in the documentation and check for it in the Makefile. Regards, Patrick. PS: The detailed output of the failed tests looks like this: perladmin@rincewind:~/cpan/build/Parallel-SubFork-0.06-LJBk7o$ perl -I ./lib t/02-task-timeout.t 1..29 ok 1 - use Parallel::SubFork::Task; ok 2 - The object isa IPC::Semaphore ok 3 - Semaphore cleared ok 4 - Semaphore cleared ok 5 - The object isa Parallel::SubFork::Task ok 6 - Taks has a different PID ok 7 - Child process still running ok 8 not ok 9 # Failed test at t/02-task-timeout.t line 65. ok 10 - Removed resource to semaphore B not ok 11 - Task exit code is fine # Failed test 'Task exit code is fine' # at /home/perladmin/cpan/build/Parallel-SubFork-0.06-LJBk7o/t/Tsemaphore.pm line 191. # got: '1' # expected: '57' not ok 12 - Task status is fine # Failed test 'Task status is fine' # at /home/perladmin/cpan/build/Parallel-SubFork-0.06-LJBk7o/t/Tsemaphore.pm line 192. # got: '14' # expected: '14592' ok 13 - Task args are intact not ok 14 - Second wait on the same task, exit code fine # Failed test 'Second wait on the same task, exit code fine' # at /home/perladmin/cpan/build/Parallel-SubFork-0.06-LJBk7o/t/Tsemaphore.pm line 202. # got: '1' # expected: '57' not ok 15 - Second wait on the same task, status fine # Failed test 'Second wait on the same task, status fine' # at /home/perladmin/cpan/build/Parallel-SubFork-0.06-LJBk7o/t/Tsemaphore.pm line 203. # got: '14' # expected: '14592' ok 16 - No more processes ok 17 - Semaphore cleared ok 18 - The object isa Parallel::SubFork::Task ok 19 - Taks has a different PID ok 20 - Child process still running ok 21 not ok 22 # Failed test at t/02-task-timeout.t line 65. ok 23 - Removed resource to semaphore B not ok 24 - Task exit code is fine # Failed test 'Task exit code is fine' # at /home/perladmin/cpan/build/Parallel-SubFork-0.06-LJBk7o/t/Tsemaphore.pm line 191. # got: '1' # expected: '57' not ok 25 - Task status is fine # Failed test 'Task status is fine' # at /home/perladmin/cpan/build/Parallel-SubFork-0.06-LJBk7o/t/Tsemaphore.pm line 192. # got: '14' # expected: '14592' ok 26 - Task args are intact not ok 27 - Second wait on the same task, exit code fine # Failed test 'Second wait on the same task, exit code fine' # at /home/perladmin/cpan/build/Parallel-SubFork-0.06-LJBk7o/t/Tsemaphore.pm line 202. # got: '1' # expected: '57' not ok 28 - Second wait on the same task, status fine # Failed test 'Second wait on the same task, status fine' # at /home/perladmin/cpan/build/Parallel-SubFork-0.06-LJBk7o/t/Tsemaphore.pm line 203. # got: '14' # expected: '14592' ok 29 - No more processes # Looks like you failed 10 tests of 29. -- Patrick Schulz Yield Engineering T +49 (0) 351 277-4233 F +49 (0) 351 277-94233 M/S: E32-YE patrick.schulz@globalfoundries.com http://www.globalfoundries.com/ GLOBALFOUNDRIES Dresden Module One Limited Liability Company & Co. KG Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Sitz Dresden I Registergericht Dresden HRA 5255 Vertretungsberechtigter Komplementär: GLOBALFOUNDRIES Dresden Module One LLC (Sitz Wilmington, Delaware, USA) Geschäftsführer der GLOBALFOUNDRIES Dresden Module One LLC: James E. Doran, Bruce McDougall, Kelly Ann Smales ------ vmunix: panic - no coffee detected, user halted.
On Thu Nov 12 05:53:40 2009, patrick.schulz@globalfoundries.com wrote: Show quoted text
> Hello, > > when I tried to install Parallel-SubFork-0.06 in our perl-5.8.8 > installation (x86_64 GNU/Linux) the tests failed like for may other > testers. Same happened with perl-5.8.9. > When I looked into the code I found that you use Time::HiRes (but it's > not mentioned in the doc).
Time::HiRes is mentioned in the doc of Parallel::SubFork::Task, but not in the module's main documentation page. Show quoted text
> After upgrading Time::HiRes from version > v1.86 to v1.9719 all tests were passed (on perl-5.8.8 and perl-5.8.9). > So it seems to be important to have the right version of Time::HiRes > installed. Please state this in the documentation and check for it in > the Makefile. >
I wasn't aware that I specific version of Time::HiRes was required. My intention was simply to detect if the module was available and to use it. That's why Time::HiRes is not listed as a mandatory dependency, if it's not available it shouldn't cause a problem. I didn't though that an old version of Time::HiRes would be problematic. Thanks for the bug report, I will update the module.
I'm a bit puzzled here. So the only call to Time::HiRes that the module does is to alarm. I've checked the logs of Time::HiRes and alarm since to exist since a long time. Could it be that upgrading Time::HiRes upgraded some other perl modules that made the test pass? The tests are relying heavily on IPC::SysV and IPC::Semaphoe, the latter seems to be broken in some systems. I've also check the documentation of ExtUtils::MakeMaker and there doesn't seem to be a way to specify optional dependencies. On the other hand what I can do is to not use Time::HiRes if I detect that it has an old version. The problem is that I don't know where to put the limit for an old version...
Subject: Re: [rt.cpan.org #51465] Dependency problem (resolved)
Date: Fri, 13 Nov 2009 20:52:37 +0100
To: "bug-Parallel-SubFork [...] rt.cpan.org" <bug-Parallel-SubFork [...] rt.cpan.org>
From: Patrick Schulz <patrick.schulz [...] globalfoundries.com>
I can understand, that you're puzzled, so am I. Unfortunately the terminal sessions are closed, I can't post the output of cpan. However, I looked in the cpan directories. The following packets were installed in my last cpan session: install Archive::Tar install Time::HiRes install CPAN install Parallel::SubFork In the build directory the following directories were created during this session: Parallel-SubFork-0.06-TVBKci.yml Parallel-SubFork-0.06-TVBKci CPAN-1.9402-4gPhpf.yml CPAN-1.9402-4gPhpf Time-HiRes-1.9719-iosbo8.yml Time-HiRes-1.9719-iosbo8 Archive-Tar-1.54-iOdpga.yml Archive-Tar-1.54-iOdpga IO-Compress-2.023-ccOuGb.yml IO-Compress-2.023-ccOuGb Compress-Raw-Zlib-2.023-yMb_o0.yml Compress-Raw-Zlib-2.023-yMb_o0 Compress-Raw-Bzip2-2.023-3MYNQC.yml Compress-Raw-Bzip2-2.023-3MYNQC Package-Constants-0.02-dvoHUL Package-Constants-0.02-dvoHUL.yml Nothing that points to IPC. Here's what I did when I used our dev machine, maybe you can reproduce the problem this way: I took a pure perl-5.8.9 (built from sources). Then I called cpan and installed the up-to date cpan module (and lots of depended modules). At the end cpan told me that it's loading a version of Time::HiRes. It looked like this: CPAN: Time::HiRes loaded ok (v1.86) What makes me wonder is that cpan did not download Time::HiRes during this update (can't find it in build dir, btw. v1.86 is pretty outdated). Is it part of perl-5.8.9 or is the cpan message misleading and Time::HiRes wasn't installed at all? Then I installed Class::Accessor::Fast and Test::Pod since they are required. Then I built and tested Parallel-SubFork - it failed. I installed Time::HiRes v1.9719 using cpan. Parallel-SubFork passed all tests after that. Why? I don't know but I'm happy now ;-) Patrick. -- Patrick Schulz Yield Engineering T +49 (0) 351 277-4233 F +49 (0) 351 277-94233 M/S: E32-YE patrick.schulz@globalfoundries.com http://www.globalfoundries.com/ GLOBALFOUNDRIES Dresden Module One Limited Liability Company & Co. KG Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland Sitz Dresden I Registergericht Dresden HRA 5255 Vertretungsberechtigter Komplementär: GLOBALFOUNDRIES Dresden Module One LLC (Sitz Wilmington, Delaware, USA) Geschäftsführer der GLOBALFOUNDRIES Dresden Module One LLC: James E. Doran, Bruce McDougall, Kelly Ann Smales ------ vmunix: panic - no coffee detected, user halted.
On Fri Nov 13 14:54:54 2009, patrick.schulz@globalfoundries.com wrote: Show quoted text
> Here's what I did when I used our dev machine, maybe you can reproduce > the problem this way: I took a pure perl-5.8.9 (built from sources).
I followed your advice and downloaded perl 5.8.9 and installed it from the sources (/opt/perl5/bin/perl). Something peculiar about this is that I ended up with Time::HiRes 1.9711 and not 1.86. What's interesting is that my unit tests also fail with that perl, but they fail for other reasons! That's not so bad as I can try to test what's going on, although this might not address your original bug. I managed to find the source of *my* problem, it seems that Time::HiRes::alarm doesn't work as expected as it's not able to wake up a syscall. This code snippet shows the problem: /opt/perl5/bin/perl -le 'use Time::HiRes; use POSIX; $SIG{ALRM} = sub {}; Time::HiRes::alarm(2); $a = time; POSIX::pause(); print time - $a;' This program never returns with perl 5.8.9 and Time::HiRes 1.9711, but runs fine with my system perl (5.10.0).
Show quoted text
> This code snippet shows the problem: > /opt/perl5/bin/perl -le 'use Time::HiRes; use POSIX; $SIG{ALRM} = sub > {}; Time::HiRes::alarm(2); $a = time; POSIX::pause(); print time - $a;' >
The problem is with the alarm implementation which uses the C functions setitimer or ualarm. Some systems put a limit to the value that can be passed 999999 (thats almost a second). I rewrote the code in order to use a sleep instead of relying on alarm. Version 0.08 will have this new change.
Uploaded version 0.08 to CPAN. Thanks for the bug report.