Bug #24286 for Win32-Process-Info: Win32::Process::Info clashes with windows fork

Tue Jan 09 11:08:47 2007 m.nooning [...] comcast.net - Ticket created

Subject:	Win32::Process::Info clashes with windows fork
Date:	Tue, 09 Jan 2007 11:08:16 -0500
To:	wyant [...] cpan.org, bug-Win32-Process-Info [...] rt.cpan.org
From:	Malcolm Nooning <m.nooning [...] comcast.net>

Hello, This email is the same as the last, except that I now included my OS and and other information. I have a code snippet, pasted further below, that always crashes the perl interpreter. I do not know if the problem is a fork bug or a Win32::Process::Info bug, so I am sending this email to both the fork() and the Win32::Process::Info listed maintainers, just in case the problem is a combination of the two together and needs coordination to resolve. Unfortunately, the email address for Gurusamy Sarathy <gsar@activestate.com> does not work, so I am trying bug-Win32-Process-Info@rt.cpan.org as a wild guess. I am using ActiveState Perl v5.8.8 Binary build 819 [267479] and I am using Win32::Process::Info version 1.0006. on an AMD Athlon 64 based Windows XP SP2 machine. Commenting out the "use" statement will make fork work. Commenting out the fork will make the "use" statement work. I could not find a report on this on the web. Any help would be appreciated. Thanks

Tue Jan 09 11:17:54 2007 m.nooning [...] comcast.net - Correspondence added

Subject:	[rt.cpan.org #24286]
Date:	Tue, 09 Jan 2007 11:17:41 -0500
To:	bug-Win32-Process-Info [...] rt.cpan.org
From:	Malcolm Nooning <m.nooning [...] comcast.net>

#---------- This code always crashes the perl interpreter #!/usr/bin/perl -w # file: test_crash_windows_fork.pl use Win32::Process::Info; if (my $pid = fork()) { print "Parent\n"; } elsif(defined $pid) { print "Child"; exit; } else { print "Failed to fork:$!:\n"; }

Tue Jan 09 16:06:56 2007 wyant [...] cpan.org - Correspondence added

M. Nooning - Thank you very much for your bug report. Unfortunately I have no Wintel equipment at my disposal at the moment. Would you be willing to execute the attached Perl script and let me know the results? I have tried to make sure it has DOS newlines, but the proof is in the execution. What this is is a blatant attempt to pass the buck, but there may be some logic in it. Your test script works as expected on my machine (Mac OS 10.3.9). You may say this is not suprising, but it may narrow things down some, since you say that "use Win32::Process::Info;" is enough to cause the script to fail, and there is some eval'ed code that doesn't get executed (at least not much) on my system. What the attached file is is your script, but with 'use' statements representing the modules included in the 'eval' code, and with 'use Win32::Process::Info;' commented out. If it still blows up, maybe the "blowup" can be isolated to one of the modules I use, in which case the buck gets passed to the author of that module. If it doesn't blow up, I may pass you the eval'ed code verbatim to see if that tells us anything. If it turns out to be me versus ActiveState, I don't know how much I can promise, unless maybe a workaround. They have nothing to do with Win32::Process::Info, and I have nothing to do with them, except that I have found that they don't answer their mail very well. At any rate the first step if I can't pass the buck is to find a Wintel machine I can use. Tom Wyant

#!/usr/bin/perl -w # file: test_crash_windows_fork.pl ## use Win32::Process::Info; use Win32::API; use Win32API::Registry; use Win32::OLE; use Win32::OLE::Const; use Win32::OLE::Variant; if (my $pid = fork()) { print "Parent\n"; } elsif(defined $pid) { print "Child\n"; exit; } else { print "Failed to fork:$!:\n"; }

Tue Jan 09 16:07:02 2007 The RT System itself - Status changed from 'new' to 'open'

Tue Jan 09 16:32:39 2007 m.nooning [...] comcast.net - Correspondence added

Subject:	Re: [rt.cpan.org #24286] Win32::Process::Info clashes with windows fork
Date:	Tue, 09 Jan 2007 16:29:35 -0500
To:	bug-Win32-Process-Info [...] rt.cpan.org
From:	Malcolm Nooning <m.nooning [...] comcast.net>

I ran your test file verbatim. I have the same results. Show quoted text

>commented out

The "use Win32::Process::Info;" was something I tried instead of what is in the eval statement. I tried a lot of things with it and I kept getting the same problem. I then commented it out and started trying the eval statement. Different variations with the eval resulted in the same problem so I gave up and reported the bug. #use Win32::API; --> Uncommenting this by itself does NOT cause the crash. #use Win32API::Registry;--> Uncommenting this by itself does NOT cause the crash. #use Win32::OLE;--> Uncommenting this by itself DOES cause the crash. #use Win32::OLE::Const;--> Uncommenting this by itself DOES cause the crash. #use Win32::OLE::Variant;--> Uncommenting this by itself DOES cause the crash. I would be pleased to try other things. What else can I try? Thanks via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=24286 > > > M. Nooning - > > Thank you very much for your bug report. > > Unfortunately I have no Wintel equipment at my disposal at the moment. > Would you be willing to execute the attached Perl script and let me know > the results? I have tried to make sure it has DOS newlines, but the > proof is in the execution. > > What this is is a blatant attempt to pass the buck, but there may be > some logic in it. Your test script works as expected on my machine (Mac > OS 10.3.9). You may say this is not suprising, but it may narrow things > down some, since you say that "use Win32::Process::Info;" is enough to > cause the script to fail, and there is some eval'ed code that doesn't > get executed (at least not much) on my system. What the attached file is > is your script, but with 'use' statements representing the modules > included in the 'eval' code, and with 'use Win32::Process::Info;' > commented out. If it still blows up, maybe the "blowup" can be isolated > to one of the modules I use, in which case the buck gets passed to the > author of that module. > > If it doesn't blow up, I may pass you the eval'ed code verbatim to see > if that tells us anything. > > If it turns out to be me versus ActiveState, I don't know how much I can > promise, unless maybe a workaround. They have nothing to do with > Win32::Process::Info, and I have nothing to do with them, except that I > have found that they don't answer their mail very well. At any rate the > first step if I can't pass the buck is to find a Wintel machine I can use. > > Tom Wyant > > ------------------------------------------------------------------------ > > #!/usr/bin/perl -w > > # file: test_crash_windows_fork.pl > > > > ## use Win32::Process::Info; > > > > use Win32::API; > > use Win32API::Registry; > > > > use Win32::OLE; > > use Win32::OLE::Const; > > use Win32::OLE::Variant; > > > > if (my $pid = fork()) { > > print "Parent\n"; > > } > > elsif(defined $pid) { > > print "Child\n"; > > exit; > > } else { > > print "Failed to fork:$!:\n"; > > } > > > >

Tue Jan 09 16:44:38 2007 m.nooning [...] comcast.net - Correspondence added

CC:	bug-Win32-Process-Info [...] rt.cpan.org
Subject:	Re: [rt.cpan.org #24286] Win32::Process::Info clashes with windows fork
Date:	Tue, 09 Jan 2007 16:44:06 -0500
To:	Malcolm Nooning <m.nooning [...] comcast.net>
From:	Malcolm Nooning <m.nooning [...] comcast.net>

I should add that, in desperation, I uninstalled Perl, went into regedit and removed all mention of perl (but not things like "hyperlink", of course), and then downloaded and installed the Windows (x86) perl, v5.8.8 built for MSWin32-x86-multi-thread, which is what I originally had. I have the same interpreter crashes. BTW: When I say "crashes", I mean that a pop up window opens with the title "Perl Command Line Interpreter" and the following verbiage. Perl Command Line Interpreter has encountered a problem and needs to close. We are sorry for the inconvenience. If you were in the moddle of something, the information you were working on might be lost. Please tell Microsoft about this problem. We have created an error report that you can send to us. We will treat this report as confidential and anonymous. Malcolm Nooning wrote: Show quoted text

> I ran your test file verbatim. I have the same results. >

> >commented out

> The "use Win32::Process::Info;" was something I tried instead of what > is in the eval statement. I tried a lot of things with it and I kept > getting the same problem. I then commented it out and started trying > the eval statement. Different variations with the eval resulted in > the same problem so I gave up and reported the bug. > > #use Win32::API; --> Uncommenting this by itself does NOT cause the > crash. > > #use Win32API::Registry;--> Uncommenting this by itself does NOT cause > the crash. > > #use Win32::OLE;--> Uncommenting this by itself DOES cause the crash. > > #use Win32::OLE::Const;--> Uncommenting this by itself DOES cause the > crash. > > #use Win32::OLE::Variant;--> Uncommenting this by itself DOES cause > the crash. > > > I would be pleased to try other things. What else can I try? > > Thanks > > via RT wrote:

>> <URL: http://rt.cpan.org/Ticket/Display.html?id=24286 > >> >> M. Nooning - >> >> Thank you very much for your bug report. >> >> Unfortunately I have no Wintel equipment at my disposal at the moment. >> Would you be willing to execute the attached Perl script and let me know >> the results? I have tried to make sure it has DOS newlines, but the >> proof is in the execution. >> >> What this is is a blatant attempt to pass the buck, but there may be >> some logic in it. Your test script works as expected on my machine (Mac >> OS 10.3.9). You may say this is not suprising, but it may narrow things >> down some, since you say that "use Win32::Process::Info;" is enough to >> cause the script to fail, and there is some eval'ed code that doesn't >> get executed (at least not much) on my system. What the attached file is >> is your script, but with 'use' statements representing the modules >> included in the 'eval' code, and with 'use Win32::Process::Info;' >> commented out. If it still blows up, maybe the "blowup" can be isolated >> to one of the modules I use, in which case the buck gets passed to the >> author of that module. >> >> If it doesn't blow up, I may pass you the eval'ed code verbatim to see >> if that tells us anything. >> >> If it turns out to be me versus ActiveState, I don't know how much I can >> promise, unless maybe a workaround. They have nothing to do with >> Win32::Process::Info, and I have nothing to do with them, except that I >> have found that they don't answer their mail very well. At any rate the >> first step if I can't pass the buck is to find a Wintel machine I can use. >> >> Tom Wyant >> >> ------------------------------------------------------------------------ >> >> #!/usr/bin/perl -w >> >> # file: test_crash_windows_fork.pl >> >> >> >> ## use Win32::Process::Info; >> >> >> >> use Win32::API; >> >> use Win32API::Registry; >> >> >> >> use Win32::OLE; >> >> use Win32::OLE::Const; >> >> use Win32::OLE::Variant; >> >> >> >> if (my $pid = fork()) { >> >> print "Parent\n"; >> >> } >> >> elsif(defined $pid) { >> >> print "Child\n"; >> >> exit; >> >> } else { >> >> print "Failed to fork:$!:\n"; >> >> } >> >> >> >>

Wed Jan 10 06:34:38 2007 m.nooning [...] comcast.net - Correspondence added

Subject:	[rt.cpan.org #24286] Win32::Process::Info clashes with windows fork
Date:	Wed, 10 Jan 2007 06:32:41 -0500
To:	bug-Win32-Process-Info [...] rt.cpan.org
From:	Malcolm Nooning <m.nooning [...] comcast.net>

Hello, This is to add that Jan Dubois jand at ActiveState dot com wrote me about this. I will paste it below. ---------------- paste I don't know about Win32::Process::Info, but you definitely cannot use Win32::OLE in a program that uses (pseudo-)fork. It is a long outstanding issue, and not trivial to implement. Maybe I'll get around to it sometime this year, but I've been saying this for a while now... Cheers, -Jan -------------end paste I see that Win32::Process::Info uses Win32::OLE for WMI.pm, but not for NT.pm. I am using only Windows2000 and above, so I sought to remove all references to Win32::OLE by stubbing out Win32::Process::Info::WMI like this: ----------paste package Win32::Process::Info::WMI; 1; ---------end paste and also, in Info.pm, I added the pound signs below ------------------paste WMI => { # make => sub { # require Win32::Process::Info::WMI; # Win32::Process::Info::WMI->new (@_); # }, # unsupported => eval { # return "I can not find Win32::OLE" # unless require Win32::OLE; # return 0; # }, }, --------------end paste and yet the fork_fail.pl you posted still has the same crash. Is there something else I could try? Thanks

Wed Jan 10 07:17:43 2007 m.nooning [...] comcast.net - Correspondence added

Subject:	[rt.cpan.org #24286] Win32::Process::Info clashes with windows fork
Date:	Wed, 10 Jan 2007 07:17:23 -0500
To:	bug-Win32-Process-Info [...] rt.cpan.org
From:	Malcolm Nooning <m.nooning [...] comcast.net>

I have the work around for Windows XP, and probably Windows 2000. Namely, what I wrote previously. I simply missed commenting out a line. It is not necessary to Stub out Win32::Process::Info::WMI. It is only necessary to comment out the section of Info.pm that I show below. ------------------paste WMI => { # make => sub { # require Win32::Process::Info::WMI; # Win32::Process::Info::WMI->new (@_); # }, # unsupported => eval { # return "I can not find Win32::OLE" # unless require Win32::OLE; # return 0; # }, }, --------------end paste

Wed Jan 10 09:44:42 2007 wyant [...] cpan.org - Correspondence added

Win32::OLE again, huh? I have already had to recommend against the WMI variant because of memory leaks. Another workaround is just to find Win32\Process\Info\WMI.pm and rename it to something else. Both this and the commenting-out have the problem that they disable the WMI variant for the entire installation. That entire eval mess was created when Aldo Calpini updated Win32::API, and it had to be loaded by 'use', by 'require' in a BEGIN block, or not at all. It sounds like what I need to do is one of two things: - Create some way to forbid the use of a given variant, probably using the import() hooks, or - Have the 'sanity check' code run at load time for the NT variant, but at execution time for the WMI variant. The latter is the minimal change in the user interface, and probably easier, but the former would provide a way to forbid the use of the WMI variant for the whole script, and I'm leaning toward it if I can make it work. If I were to cold-code something up, would you be willing to test it? Would you take a CPAN-style distribution (which requires you to install nmake, or to hand-move the .pm files to their proper places)? I _may_ be able to make a PPM package you can use (I just discovered the existence of PPM::Make yesterday, though I could attempt it anyway), but I can't guarantee that I can. Thanks for the checking, and for sharing the definitive response from ActiveState. Tom Wyant

Wed Jan 10 09:48:42 2007 m.nooning [...] comcast.net - Correspondence added

Subject:	Re: [rt.cpan.org #24286] Win32::Process::Info clashes with windows fork
Date:	Wed, 10 Jan 2007 09:48:20 -0500
To:	bug-Win32-Process-Info [...] rt.cpan.org
From:	Malcolm Nooning <m.nooning [...] comcast.net>

I would be glad to test whatever you send. I will make it a high priority. Thank you for doing what you do. via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=24286 > > > Win32::OLE again, huh? I have already had to recommend against the WMI > variant because of memory leaks. > > Another workaround is just to find Win32\Process\Info\WMI.pm and rename > it to something else. Both this and the commenting-out have the problem > that they disable the WMI variant for the entire installation. > > That entire eval mess was created when Aldo Calpini updated Win32::API, > and it had to be loaded by 'use', by 'require' in a BEGIN block, or not > at all. > > It sounds like what I need to do is one of two things: > > - Create some way to forbid the use of a given variant, probably using > the import() hooks, or > > - Have the 'sanity check' code run at load time for the NT variant, but > at execution time for the WMI variant. > > The latter is the minimal change in the user interface, and probably > easier, but the former would provide a way to forbid the use of the WMI > variant for the whole script, and I'm leaning toward it if I can make it > work. > > If I were to cold-code something up, would you be willing to test it? > Would you take a CPAN-style distribution (which requires you to install > nmake, or to hand-move the .pm files to their proper places)? I _may_ be > able to make a PPM package you can use (I just discovered the existence > of PPM::Make yesterday, though I could attempt it anyway), but I can't > guarantee that I can. > > Thanks for the checking, and for sharing the definitive response from > ActiveState. > > Tom Wyant > >

Wed Jan 10 12:42:45 2007 wyant [...] cpan.org - Correspondence added

On Wed Jan 10 09:48:42 2007, m.nooning@comcast.net wrote: Show quoted text

> I would be glad to test whatever you send. I will make it a high

priority. Show quoted text

> Thank you for doing what you do. >

Thank you. I hope to have something today or tomorrow. What I intend is if you want to completely disable the WMI variant, you use Win32::Process::Info qw{NT}; This will prevent the script from loading Win32::OLE while trying to figure out if the WMI variant can be used. At the same time it will be available to other scripts that (e.g.) don't use fork(). Tom Wyant

Wed Jan 10 20:50:39 2007 wyant [...] cpan.org - Correspondence added

Malcolm, Could you give the attached a try? I _believe_ all the files have DOS line endings except for META.yml, which gets regenerated as part of the build process. I believe WINZIP will handle the .tar.gz. If you have 'nmake' installed you can do the usual incantation from the directory the tarball expanded into: Show quoted text

> perl Makefile.PL > nmake > nmake test > nmake install

Or, you can just take the files Info.pm, Info\NT.pm, and Info\WMI.pm from the kit (they're under lib\Win32\Process) and drop them the right place in your @INC directories (saving the old ones in case I screwed something up badly). Please let me know what happens. Thanks, Tom

Download Win32-Process-Info-1.006_01.tar.gz
application/x-gzip 28.1k

Message body not shown because it is not plain text.

Wed Jan 10 21:05:17 2007 m.nooning [...] comcast.net - Correspondence added

Subject:	Re: [rt.cpan.org #24286] Win32::Process::Info clashes with windows fork
Date:	Wed, 10 Jan 2007 21:04:49 -0500
To:	bug-Win32-Process-Info [...] rt.cpan.org
From:	Malcolm Nooning <m.nooning [...] comcast.net>

Hello, I have a test error. Is there a command line switch or something I can run that will help show up the error better? I tried -d, as shown, and it showed a little more information, but not much. --------------------paste C:\temp\Win32-Process-Info-1.006_01>nmake test -d Microsoft (R) Program Maintenance Utility Version 7.00.9466 Copyright (C) Microsoft Corporation. All rights reserved. Makefile.PL Wed Jan 10 19:50:37 2007 C:\Perl\lib\Config.pm Tue Jan 09 15:30:31 2007 C:\Perl\lib\CORE\config.h Tue Jan 09 15:30:31 2007 Makefile Wed Jan 10 20:59:45 2007 C:\Perl\lib\CORE\perl.h Wed Mar 15 13:23:04 2006 C:\Perl\lib\CORE\perl.h Wed Mar 15 13:23:04 2006 C:\Perl\lib\CORE\perl.h Wed Mar 15 13:23:04 2006 C:\Perl\lib\CORE\perl.h Wed Mar 15 13:23:04 2006 lib/Win32/Process/Info.pm Wed Jan 10 19:50:37 2007 lib/Win32/Process/Info/NT.pm Wed Jan 10 19:50:37 2007 lib/Win32/Process/Info/WMI.pm Wed Jan 10 19:50:37 2007 pm_to_blib Wed Jan 10 20:59:48 2007 Makefile Wed Jan 10 20:59:45 2007 C:\perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib\lib', 'blib\arch')" t\basic.t t\pod.t t\pod_coverage.t t\basic...........ok t\pod.............ok t\pod_coverage.... t\pod_coverage....NOK 1# Failed test 'Pod coverage on Encode::RAD50' # in t\pod_coverage.t at line 14. # Encode::RAD50: couldn't find pod # Looks like you failed 1 test of 1. t\pod_coverage....dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 1 Failed 1/1 tests, 0.00% okay Failed Test Stat Wstat Total Fail Failed List of Failed ------------------------------------------------------------------------------- t\pod_coverage.t 1 256 1 1 100.00% 1 Failed 1/3 test scripts, 66.67% okay. 1/20 subtests failed, 95.00% okay. NMAKE : fatal error U1077: 'C:\perl\bin\perl.exe' : return code '0x1' Stop. via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=24286 > > > Malcolm, > > Could you give the attached a try? I _believe_ all the files have DOS > line endings except for META.yml, which gets regenerated as part of the > build process. I believe WINZIP will handle the .tar.gz. > > If you have 'nmake' installed you can do the usual incantation from the > directory the tarball expanded into: > >

>> perl Makefile.PL >> nmake >> nmake test >> nmake install >>

> > Or, you can just take the files Info.pm, Info\NT.pm, and Info\WMI.pm > from the kit (they're under lib\Win32\Process) and drop them the right > place in your @INC directories (saving the old ones in case I screwed > something up badly). > > Please let me know what happens. > > Thanks, > Tom >

Wed Jan 10 21:28:21 2007 m.nooning [...] comcast.net - Correspondence added

Subject:	Re: [rt.cpan.org #24286] Win32::Process::Info clashes with windows fork
Date:	Wed, 10 Jan 2007 21:28:01 -0500
To:	bug-Win32-Process-Info [...] rt.cpan.org
From:	Malcolm Nooning <m.nooning [...] comcast.net>

I copied over the files manually. They made no difference. I still get the same crash. via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=24286 > > > Malcolm, > > Could you give the attached a try? I _believe_ all the files have DOS > line endings except for META.yml, which gets regenerated as part of the > build process. I believe WINZIP will handle the .tar.gz. > > If you have 'nmake' installed you can do the usual incantation from the > directory the tarball expanded into: > >

>> perl Makefile.PL >> nmake >> nmake test >> nmake install >>

> > Or, you can just take the files Info.pm, Info\NT.pm, and Info\WMI.pm > from the kit (they're under lib\Win32\Process) and drop them the right > place in your @INC directories (saving the old ones in case I screwed > something up badly). > > Please let me know what happens. > > Thanks, > Tom >

Wed Jan 10 21:34:40 2007 m.nooning [...] comcast.net - Correspondence added

Subject:	Re: [rt.cpan.org #24286] Win32::Process::Info clashes with windows fork
Date:	Wed, 10 Jan 2007 21:34:16 -0500
To:	bug-Win32-Process-Info [...] rt.cpan.org
From:	Malcolm Nooning <m.nooning [...] comcast.net>

It works. I forgot to do use Win32::Process::Info qw{NT}; instead of use Win32::Process::Info; in my test file. Sorry about that. Excellent via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=24286 > > > Malcolm, > > Could you give the attached a try? I _believe_ all the files have DOS > line endings except for META.yml, which gets regenerated as part of the > build process. I believe WINZIP will handle the .tar.gz. > > If you have 'nmake' installed you can do the usual incantation from the > directory the tarball expanded into: > >

>> perl Makefile.PL >> nmake >> nmake test >> nmake install >>

> > Or, you can just take the files Info.pm, Info\NT.pm, and Info\WMI.pm > from the kit (they're under lib\Win32\Process) and drop them the right > place in your @INC directories (saving the old ones in case I screwed > something up badly). > > Please let me know what happens. > > Thanks, > Tom >

Thu Jan 11 09:29:04 2007 wyant [...] cpan.org - Correspondence added

Thank you very much for running the tests. As it turns out, the information you gave was plenty to resolve the test failure, which was the result of copying test files from another distribution and not making all the needed changes. The command you were looking for is the rather verbose and clumsy nmake test TEST_VERBOSE=1 TEST_FILES=t/pod_coverage.t though for my purposes perl -Mblib t/pod_coverage.t would have been sufficient and much easier. As it turns out, though, I do not at the moment need the output of either. In fixing this one up I made some internal changes to Win32::Process::Info. Would you be so good as to both 'nmake test' the attached and try the new Info.pm (etc) files in your application? I have put some weasel words in about the 'use Win32::Process::Info qw{NT}' mechanism maybe changing. There are two issues here, but I think the only real show-stopper would be if the CPAN distribution failed to make it into ActiveState's PPM repository. I had a problem once with using Exporter (the class that normally supplies the import() method) in a non-standard way. Here I am not using Exporter at all, merely supplying my own import() method; I do not know if this will trigger the behaviour I saw before, or if it was a fluke. The other issue (probably not a show-stopper) is that I seem to recall that there was a CPAN module that used Win32::Process::Info as a prerequisite. Unfortunately the only easy source I have for prerequisites is http://cpants.perl.org/ and that is currently being rebuilt. The only other thing I can think of is to download all of CPAN and paw through the prerequisites of each. I was hoping to avoid this. At any event, users of the "other" module can do 'use Win32::Process::Info qw{NT};' first, and then load the other module. Sorry for the long note, and thanks again for your assistance. Please let me know how the new kit works. Tom Wyant

Download Win32-Process-Info-1.006_02.tar.gz
application/x-gzip 28.3k

Message body not shown because it is not plain text.

Thu Jan 11 09:46:39 2007 m.nooning [...] comcast.net - Correspondence added

Subject:	Re: [rt.cpan.org #24286] Win32::Process::Info clashes with windows fork
Date:	Thu, 11 Jan 2007 09:46:16 -0500
To:	bug-Win32-Process-Info [...] rt.cpan.org
From:	Malcolm Nooning <m.nooning [...] comcast.net>

The tests fail -----------------------------paste first attempt C:\temp\Win32-Process-Info-1.006_02>nmake test Microsoft (R) Program Maintenance Utility Version 7.00.9466 Copyright (C) Microsoft Corporation. All rights reserved. C:\perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib\lib', 'blib\arch')" t\basic .t t\pod.t t\pod_coverage.t t\basic...........ok t\pod.............ok t\pod_coverage....ok 1/3Too late to run INIT block at C:/perl/site/lib/Win32/API/Type.pm line 71. t\pod_coverage....NOK 2# Failed test 'Pod coverage on Win32::Process::Info::NT' # in C:/perl/site/lib/Test/Pod/Coverage.pm at line 126. # Coverage for Win32::Process::Info::NT is 60.0%, with 2 naked subroutines: # TokenOwner # TokenUser # Looks like you failed 1 test of 3. t\pod_coverage....dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 2 Failed 1/3 tests, 66.67% okay Failed Test Stat Wstat Total Fail Failed List of Failed ------------------------------------------------------------------------------- t\pod_coverage.t 1 256 3 1 33.33% 2 Failed 1/3 test scripts, 66.67% okay. 1/22 subtests failed, 95.45% okay. NMAKE : fatal error U1077: 'C:\perl\bin\perl.exe' : return code '0x1' Stop. -------------------end paste ------------------------------------paste second attempt C:\temp\Win32-Process-Info-1.006_02>nmake test TEST_VERBOSE=1 TEST_FILES=t/pod_coverage.t Microsoft (R) Program Maintenance Utility Version 7.00.9466 Copyright (C) Microsoft Corporation. All rights reserved. C:\perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(1, 'blib\lib', 'blib\arch')" t/pod_c overage.t t/pod_coverage....1..3 ok 1 - Pod coverage on Win32::Process::Info Too late to run INIT block at C:/perl/site/lib/Win32/API/Type.pm line 71. not ok 2 - Pod coverage on Win32::Process::Info::NT # Failed test 'Pod coverage on Win32::Process::Info::NT' # in C:/perl/site/lib/Test/Pod/Coverage.pm at line 126. # Coverage for Win32::Process::Info::NT is 60.0%, with 2 naked subroutines: # TokenOwner # TokenUser # Looks like you failed 1 test of 3. ok 3 - Pod coverage on Win32::Process::Info::WMI dubious Test returned status 1 (wstat 256, 0x100) DIED. FAILED test 2 Failed 1/3 tests, 66.67% okay Failed Test Stat Wstat Total Fail Failed List of Failed ------------------------------------------------------------------------------- t/pod_coverage.t 1 256 3 1 33.33% 2 Failed 1/1 test scripts, 0.00% okay. 1/3 subtests failed, 66.67% okay. NMAKE : fatal error U1077: 'C:\perl\bin\perl.exe' : return code '0x1' Stop. C:\temp\Win32-Process-Info-1.006_02> ------------------------end paste ---------------------ah, I now see how the perl -Mblib ... line works. ----paste C:\temp\Win32-Process-Info-1.006_02>perl -Mblib t/pod_coverage.t 1..3 ok 1 - Pod coverage on Win32::Process::Info not ok 2 - Pod coverage on Win32::Process::Info::NT # Failed test 'Pod coverage on Win32::Process::Info::NT' # in C:/perl/site/lib/Test/Pod/Coverage.pm at line 126. # Coverage for Win32::Process::Info::NT is 60.0%, with 2 naked subroutines: # TokenOwner # TokenUser ok 3 - Pod coverage on Win32::Process::Info::WMI # Looks like you failed 1 test of 3. C:\temp\Win32-Process-Info-1.006_02> ------------------end paste via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=24286 > > > Thank you very much for running the tests. As it turns out, the > information you gave was plenty to resolve the test failure, which was > the result of copying test files from another distribution and not > making all the needed changes. > > The command you were looking for is the rather verbose and clumsy > > nmake test TEST_VERBOSE=1 TEST_FILES=t/pod_coverage.t > > though for my purposes > > perl -Mblib t/pod_coverage.t > > would have been sufficient and much easier. As it turns out, though, I > do not at the moment need the output of either. > > In fixing this one up I made some internal changes to > Win32::Process::Info. Would you be so good as to both 'nmake test' the > attached and try the new Info.pm (etc) files in your application? > > I have put some weasel words in about the 'use Win32::Process::Info > qw{NT}' mechanism maybe changing. There are two issues here, but I think > the only real show-stopper would be if the CPAN distribution failed to > make it into ActiveState's PPM repository. I had a problem once with > using Exporter (the class that normally supplies the import() method) in > a non-standard way. Here I am not using Exporter at all, merely > supplying my own import() method; I do not know if this will trigger the > behaviour I saw before, or if it was a fluke. > > The other issue (probably not a show-stopper) is that I seem to recall > that there was a CPAN module that used Win32::Process::Info as a > prerequisite. Unfortunately the only easy source I have for > prerequisites is http://cpants.perl.org/ and that is currently being > rebuilt. The only other thing I can think of is to download all of CPAN > and paw through the prerequisites of each. I was hoping to avoid this. > At any event, users of the "other" module can do 'use > Win32::Process::Info qw{NT};' first, and then load the other module. > > Sorry for the long note, and thanks again for your assistance. Please > let me know how the new kit works. > > Tom Wyant >

Thu Jan 11 13:47:11 2007 wyant [...] cpan.org - Correspondence added

On Thu Jan 11 09:46:39 2007, m.nooning@comcast.net wrote: Show quoted text

> The tests fail > > -----------------------------paste first attempt > C:\temp\Win32-Process-Info-1.006_02>nmake test > > Microsoft (R) Program Maintenance Utility Version 7.00.9466 > Copyright (C) Microsoft Corporation. All rights reserved. > > C:\perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" > "test_harness(0, 'blib\lib', 'blib\arch')" t\basic > .t t\pod.t t\pod_coverage.t > t\basic...........ok > t\pod.............ok > t\pod_coverage....ok 1/3Too late to run INIT block at > C:/perl/site/lib/Win32/API/Type.pm line 71. > > t\pod_coverage....NOK 2# Failed test 'Pod coverage on > Win32::Process::Info::NT' > # in C:/perl/site/lib/Test/Pod/Coverage.pm at line 126. > # Coverage for Win32::Process::Info::NT is 60.0%, with 2 naked > subroutines: > # TokenOwner > # TokenUser > # Looks like you failed 1 test of 3. > t\pod_coverage....dubious > Test returned status 1 (wstat 256, 0x100) > DIED. FAILED test 2 > Failed 1/3 tests, 66.67% okay > Failed Test Stat Wstat Total Fail Failed List of Failed >

------------------------------------------------------------------------------- Show quoted text

> t\pod_coverage.t 1 256 3 1 33.33% 2 > Failed 1/3 test scripts, 66.67% okay. 1/22 subtests failed, 95.45% > okay. > NMAKE : fatal error U1077: 'C:\perl\bin\perl.exe' : return code '0x1' > Stop.

Well, expletive deleted. This is getting to be a pain. I _think_ the "Too late to execute INIT block" is not fatal. If it is, I'll have to retract the test completely, since it's a consequence of the way Win32::API is coded. Are you game for one more try? You are invited to review the documentation, as well, since I have thrown in a bunch of words on the consequences of the change. Thank you very much for your willingness to help me sort this mess out. Tom Wyant

Download Win32-Process-Info-1.006_03.tar.gz
application/x-gzip 29.9k

Message body not shown because it is not plain text.

Thu Jan 11 14:34:19 2007 m.nooning [...] comcast.net - Correspondence added

Subject:	Re: [rt.cpan.org #24286] Win32::Process::Info clashes with windows fork
Date:	Thu, 11 Jan 2007 14:33:50 -0500
To:	bug-Win32-Process-Info [...] rt.cpan.org
From:	Malcolm Nooning <m.nooning [...] comcast.net>

SUCCESS! No errors, no warnings. BTW: in the fork_fail.pm, if you remove the " -w" from "#!/usr/bin/perl -w" then the "too late to run INIT block ... " message goes away. I kept it in, and it still went away. Whatever you did seems to have fixed everything. Show quoted text

>willingness to help

I am just gald you are doing it. --------------------------------------------------------------------paste from command line C:\temp\Win32-Process-Info-1.006_03>nmake test Microsoft (R) Program Maintenance Utility Version 7.00.9466 Copyright (C) Microsoft Corporation. All rights reserved. C:\perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib\lib', 'blib\arch')" t\basic .t t\pod.t t\pod_coverage.t t\basic...........ok t\pod.............ok t\pod_coverage....ok All tests successful. Files=3, Tests=20, 10 wallclock secs ( 0.00 cusr + 0.00 csys = 0.00 CPU) C:\temp\Win32-Process-Info-1.006_03>nmake install Microsoft (R) Program Maintenance Utility Version 7.00.9466 Copyright (C) Microsoft Corporation. All rights reserved. Installing C:\Perl\site\lib\Win32\Process\Info.pm Skipping C:\Perl\site\lib\Win32\Process\Info\NT.pm (unchanged) Skipping C:\Perl\site\lib\Win32\Process\Info\WMI.pm (unchanged) Writing C:\Perl\site\lib\auto\Win32\Process\Info\.packlist Appending installation info to C:\Perl\site\lib/perllocal.pod C:\temp\Win32-Process-Info-1.006_03> cd c:\temp C:\temp>fork_fail.pl Parent Child C:\temp>type fork_fail.pl #!/usr/bin/perl -w #use Win32::API; #use Win32API::Registry; #use Win32::OLE; #use Win32::OLE::Const; #use Win32::OLE::Variant; #use Win32::Process::List; use Win32::Process::Info qw{NT}; if (my $pid = fork()) { print "Parent\n"; } elsif(defined $pid) { print "Child\n"; exit; } else { print "Failed to fork:$!:\n"; } C:\temp> -------------------------------------------------------------------- end paste from command line via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=24286 > > > On Thu Jan 11 09:46:39 2007, m.nooning@comcast.net wrote: >

>> The tests fail >> >> -----------------------------paste first attempt >> C:\temp\Win32-Process-Info-1.006_02>nmake test >> >> Microsoft (R) Program Maintenance Utility Version 7.00.9466 >> Copyright (C) Microsoft Corporation. All rights reserved. >> >> C:\perl\bin\perl.exe "-MExtUtils::Command::MM" "-e" >> "test_harness(0, 'blib\lib', 'blib\arch')" t\basic >> .t t\pod.t t\pod_coverage.t >> t\basic...........ok >> t\pod.............ok >> t\pod_coverage....ok 1/3Too late to run INIT block at >> C:/perl/site/lib/Win32/API/Type.pm line 71. >> >> t\pod_coverage....NOK 2# Failed test 'Pod coverage on >> Win32::Process::Info::NT' >> # in C:/perl/site/lib/Test/Pod/Coverage.pm at line 126. >> # Coverage for Win32::Process::Info::NT is 60.0%, with 2 naked >> subroutines: >> # TokenOwner >> # TokenUser >> # Looks like you failed 1 test of 3. >> t\pod_coverage....dubious >> Test returned status 1 (wstat 256, 0x100) >> DIED. FAILED test 2 >> Failed 1/3 tests, 66.67% okay >> Failed Test Stat Wstat Total Fail Failed List of Failed >> >>

> ------------------------------------------------------------------------------- >

>> t\pod_coverage.t 1 256 3 1 33.33% 2 >> Failed 1/3 test scripts, 66.67% okay. 1/22 subtests failed, 95.45% >> okay. >> NMAKE : fatal error U1077: 'C:\perl\bin\perl.exe' : return code '0x1' >> Stop. >>

> > > Well, expletive deleted. > > This is getting to be a pain. I _think_ the "Too late to execute INIT > block" is not fatal. If it is, I'll have to retract the test completely, > since it's a consequence of the way Win32::API is coded. > > Are you game for one more try? You are invited to review the > documentation, as well, since I have thrown in a bunch of words on the > consequences of the change. > > Thank you very much for your willingness to help me sort this mess out. > > Tom Wyant >

Thu Jan 11 15:42:14 2007 wyant [...] cpan.org - Correspondence added

On Thu Jan 11 14:34:19 2007, m.nooning@comcast.net wrote: Show quoted text

> SUCCESS! > No errors, no warnings. > > BTW: in the fork_fail.pm, if you remove the " -w" from > "#!/usr/bin/perl > -w" then the > "too late to run INIT block ... " > message goes away. I kept it in, and it still went away. Whatever > you > did seems to have fixed everything.

WONDERFUL! I'm sure there's a way to control this even in the presence of -w, but it is not obvious to me what the 'use warnings' option is that controls this. There does not seem to be a 'no warnings qw{toolate};'. I have just submitted version 1.007 to CPAN. It is the same as 1.006_03, except for the version number. It will probably appear on CPAN mirrors in the next day or so, but it may take another couple weeks for it to hit the ActiveState PPM repository. I'll try to keep an eye on it. At the moment I believe that this is resolved, but I will leave the ticket open until the code arrives at ActiveState (or until I get tired of waiting for them -- a couple weeks, anyway). Thanks again for your help. Tom Wyant

Fri Jan 19 10:47:44 2007 wyant [...] cpan.org - Correspondence added

Well, I said I would leave the bug open until the new package made the ActivePerl PPM repository. It failed to do so sometime overnight. The only output I have is Makefile out-of-date with respect to Makefile.PL Cleaning current config before rebuilding Makefile... nmake -f Makefile.old cle Microsof D:\cpanrun\build\5-8-0\bin\perl.exe Makefile.PL Checking if your kit is complete... Looks good Writing Makefile for WNMAKE : fatal error U1077: 'false' : return code '0x1' Stop. => Please rerun the nmake command. <== false I find most of this monumentally unhelpful, but the first line sounds to me like something flaky on ActiveState's end, since the Makefile was _not_ in the tarball. So I'm sending it through again. The docs have been tweaked a bit - or considerably in the case of include(), where it looks like my proofreading was far less than adequate. Tom Wyant

Fri Jan 19 19:11:04 2007 m.nooning [...] comcast.net - Correspondence added

Subject:	Re: [rt.cpan.org #24286] Win32::Process::Info clashes with windows fork
Date:	Fri, 19 Jan 2007 19:10:31 -0500
To:	bug-Win32-Process-Info [...] rt.cpan.org
From:	Malcolm Nooning <m.nooning [...] comcast.net>

1.008 worked fine for me. I downloaded Win32-Process-Info-1.008.tar.gz <http://search.cpan.org/CPAN/authors/id/W/WY/WYANT/Win32-Process-Info-1.008.tar.gz> from http://search.cpan.org/~wyant/Win32-Process-Info-1.008/lib/Win32/Process/Info.pm into a fresh directory. Then I did Perl Makefile.PL nmake nmake test nmake install and then ran fork_fail.pl again. As before, it works fine on Windows XP Home, ActiveState Perl 5.8.8 Show quoted text

>Makefile out-of-date with respect to Makefile.PL

Try running nmake clean and then rerun "Perl Makefile.PL", etcetera. BTW: I just went to http://search.cpan.org/~wyant/Win32-Process-Info-1.008/lib/Win32/Process/Info.pm to double check the address where I downloaded it from, and now I get "Not Found". I guess the web site is still in transition. via RT wrote: Show quoted text

> <URL: http://rt.cpan.org/Ticket/Display.html?id=24286 > > > Well, I said I would leave the bug open until the new package made the > ActivePerl PPM repository. It failed to do so sometime overnight. The > only output I have is > > Makefile out-of-date with respect to Makefile.PL > Cleaning current config before rebuilding Makefile... > nmake -f Makefile.old cle > Microsof D:\cpanrun\build\5-8-0\bin\perl.exe Makefile.PL > Checking if your kit is complete... > Looks good > Writing Makefile for WNMAKE : fatal error U1077: 'false' : return code '0x1' > Stop. > => Please rerun the nmake command. <== > false > > I find most of this monumentally unhelpful, but the first line sounds to > me like something flaky on ActiveState's end, since the Makefile was > _not_ in the tarball. So I'm sending it through again. The docs have > been tweaked a bit - or considerably in the case of include(), where it > looks like my proofreading was far less than adequate. > > Tom Wyant > >

Sun Jan 28 11:14:43 2007 wyant [...] cpan.org - Correspondence added

Well, 1.008 appears to have made it to the ActivePerl repository successfully, so I'm going to close the ticket. Thanks again for the report, and for the work done to get this resolved.

Sun Jan 28 11:18:46 2007 wyant [...] cpan.org - Status changed from 'open' to 'resolved'