Skip Menu |

This queue is for tickets about the Win32-Process-Info CPAN distribution.

Report information
The Basics
Id: 83104
Status: resolved
Priority: 0/
Queue: Win32-Process-Info

People
Owner: Nobody in particular
Requestors: MITHUN [...] cpan.org
Cc:
AdminCc:

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



Subject: WMI variant fails to load on Cygwin
The WMI variance is un-useable on Cygwin. It fails to initialize with the following message: "WMI broken: unable to get process object" This is because of the following line: $wmi and $proc = $wmi->Get( "Win32_Process='$$'" ); where `$$` is the Cygwin pid and not a Windows pid. From my testing, updating it to the following seemed to resolve the issue. my $_testpid = ( $^O =~ /cygwin/i ) ? Cygwin::pid_to_winpid($$) : $$; $wmi and $proc = $wmi->Get( "Win32_Process='$_testpid'" ); Thanks, -- Mithun
On Sat Feb 02 17:33:23 2013, MITHUN wrote: Show quoted text
> The WMI variance is un-useable on Cygwin. It fails to initialize with > the following message: > > "WMI broken: unable to get process object" > > This is because of the following line: > > $wmi and $proc = $wmi->Get( "Win32_Process='$$'" ); > > where `$$` is the Cygwin pid and not a Windows pid. From my testing, > updating it to the > following seemed to resolve the issue. > > my $_testpid = ( $^O =~ /cygwin/i ) ? Cygwin::pid_to_winpid($$) : > $$; > $wmi and $proc = $wmi->Get( "Win32_Process='$_testpid'" ); > > Thanks, > -- Mithun
Unfortunately I do not have access to a Windows machine at this time (nor for a while, actually) so I am going to have to rely some on you to get this right. Before I dive in I have a couple questions: 1) The $$ variable appears several places in the code and tests other than the one you point out. Do all these need to be changed? If not, why not? I ask this because it looks to me like they do, and if they do not I would like to understand why not. 2) It appears that Cygwin Perl makes $$ the Cygwin process ID rather than the Windows one. Do you believe this means Win32::Process::Info should return Cygwin process IDs rather than Windows process IDs? I'm pretty sure I can handle (1). (2) will be harder, but it may be the right thing to do given how the module works under other operating systems. On the other hand, if the NT variant works under Cygwin, any Cygwin users are used to getting Windows process IDs, and Cygwin process IDs will represent a change in behavior.
On Mon Feb 04 12:10:04 2013, WYANT wrote: Show quoted text
> On Sat Feb 02 17:33:23 2013, MITHUN wrote:
> > The WMI variance is un-useable on Cygwin. It fails to initialize with > > the following message: > > > > "WMI broken: unable to get process object" > > > > This is because of the following line: > > > > $wmi and $proc = $wmi->Get( "Win32_Process='$$'" ); > > > > where `$$` is the Cygwin pid and not a Windows pid. From my testing, > > updating it to the > > following seemed to resolve the issue. > > > > my $_testpid = ( $^O =~ /cygwin/i ) ? Cygwin::pid_to_winpid($$) : > > $$; > > $wmi and $proc = $wmi->Get( "Win32_Process='$_testpid'" ); > > > > Thanks, > > -- Mithun
> > Unfortunately I do not have access to a Windows machine at this time > (nor for a while, actually) so I am going to have to rely some on you to > get this right. > > Before I dive in I have a couple questions: > > 1) The $$ variable appears several places in the code and tests other > than the one you point out. Do all these need to be changed? If not, why > not? I ask this because it looks to me like they do, and if they do not > I would like to understand why not.
I think a `Cygwin::pid_to_winpid` (or vice-versa) conversion is required based on the context. In most cases the module is interrogating Win32 and it probably should be using the Windows PID. In the PT variant, it should probably leave `$$` as-is, since PT is cygwin aware and makes distinctions between Cygwin/Windows PIDS ( or so I think - from my testing). Show quoted text
> > 2) It appears that Cygwin Perl makes $$ the Cygwin process ID rather > than the Windows one. Do you believe this means Win32::Process::Info > should return Cygwin process IDs rather than Windows process IDs?
No. I think most people (including myself) use this primarily for Win32 processes. Show quoted text
> > I'm pretty sure I can handle (1). (2) will be harder, but it may be the > right thing to do given how the module works under other operating > systems. On the other hand, if the NT variant works under Cygwin, any > Cygwin users are used to getting Windows process IDs, and Cygwin process > IDs will represent a change in behavior.
The NT variant does work under cygwin - and it provides Windows PIDs only. So yes, changing this might surprise some folks unless NT gets priority over WMI on cygwin. Since the primary usage for this is on MSWin32, the NT/WMI variants can possibly start returning a CYGWINPID (?) for cygwin processes that have a different windows PID. -- Mithun
Win32-Process-Info 0.019_01 just went to CPAN. Please let me know how it works. I may have overdone the $$ conversion, but fortunately someone has put up, just in the last couple weeks, a LARGE Cygwin CPAN-testers farm. So we should know in a couple days even if neither of us lifts a finger.
On Wed Feb 06 22:28:32 2013, WYANT wrote: Show quoted text
> Win32-Process-Info 0.019_01 just went to CPAN. Please let me know how it > works. I may have overdone the $$ conversion, but fortunately someone > has put up, just in the last couple weeks, a LARGE Cygwin CPAN-testers > farm. So we should know in a couple days even if neither of us lifts a > finger.
All three variants (NT, WMI and PT) work as expected for me. Thanks much for the quick fix! -- Mithun
On Thu Feb 07 16:38:48 2013, MITHUN wrote: Show quoted text
> On Wed Feb 06 22:28:32 2013, WYANT wrote:
> > Win32-Process-Info 0.019_01 just went to CPAN. Please let me know how it > > works. I may have overdone the $$ conversion, but fortunately someone > > has put up, just in the last couple weeks, a LARGE Cygwin CPAN-testers > > farm. So we should know in a couple days even if neither of us lifts a > > finger.
> > All three variants (NT, WMI and PT) work as expected for me. > > Thanks much for the quick fix! > > -- Mithun
Glad to know it works for you. I think I will wait for CPAN testers to provide some results before doing a production release, but it sounds like there is nothing seriously wrong. I did find one omission though. With your permission I would like to add the following to the Changes entry: Thanks to Mithun Ayachit for letting me know about the $$ problem under Cygwin and providing the solution.
On Fri Feb 08 09:33:46 2013, WYANT wrote: Show quoted text
> On Thu Feb 07 16:38:48 2013, MITHUN wrote:
> > On Wed Feb 06 22:28:32 2013, WYANT wrote:
> > > Win32-Process-Info 0.019_01 just went to CPAN. Please let me know how it > > > works. I may have overdone the $$ conversion, but fortunately someone > > > has put up, just in the last couple weeks, a LARGE Cygwin CPAN-testers > > > farm. So we should know in a couple days even if neither of us lifts a > > > finger.
> > > > All three variants (NT, WMI and PT) work as expected for me. > > > > Thanks much for the quick fix! > > > > -- Mithun
> > Glad to know it works for you. I think I will wait for CPAN testers to > provide some results before doing a production release, but it sounds > like there is nothing seriously wrong.
I agree. That would be the right thing to do. Show quoted text
> > I did find one omission though. With your permission I would like to add > the following to the Changes entry: > > Thanks to Mithun Ayachit for letting me know about the $$ problem under > Cygwin and providing the solution.
Sure. Of course, I only provided a recommendation. The solution was yours :-). -- Mithun
I had to rethink the way I determine the owner's process ID under Cygwin. Luckily there are now CPAN testers that do both Win32 and Cygwin, and I had a test result that says the implementation in 1.019_01 broke the tests under the PT variant (which is based on Proc::ProcessTable). If you do not have Proc::ProcessTable installed, you would have had no trouble with 1.019_01. So 1.019_03 just went to CPAN. The $MY_PID global variable in 1.019_01 has been replaced by a My_Pid() method. That way I can override it in Win32::Process::Info::PT, so that it returns $$ even under Cygwin. If you have time, gumption, and whatever else available, would you be so good as to test 1.019_03, to see if I broke anything? CPAN testers will let me know eventually, but if you can get to it I get faster feedback and you get faster turnaround. Thanks, Tom
On Thu Feb 14 13:27:07 2013, WYANT wrote: Show quoted text
> I had to rethink the way I determine the owner's process ID under > Cygwin. Luckily there are now CPAN testers that do both Win32 and > Cygwin, and I had a test result that says the implementation in 1.019_01 > broke the tests under the PT variant (which is based on Proc::ProcessTable). > > If you do not have Proc::ProcessTable installed, you would have had no > trouble with 1.019_01. > > So 1.019_03 just went to CPAN. The $MY_PID global variable in 1.019_01 > has been replaced by a My_Pid() method. That way I can override it in > Win32::Process::Info::PT, so that it returns $$ even under Cygwin. > > If you have time, gumption, and whatever else available, would you be so > good as to test 1.019_03, to see if I broke anything? CPAN testers will > let me know eventually, but if you can get to it I get faster feedback > and you get faster turnaround. > > Thanks, > Tom
I already installed 1.019_03 in a dev environment earlier this morning and I haven't seen any issues so far. I do have P::PT installed. However, most of my usage forces the WMI variant on both Win32 and Cygwin. I will update this ticket if I notice anything broken. -- Mithun