Fix kill(0, $pid) on Windows

I broke the kill(0, $pid) behavior on Windows with change
29605
(the one implementing killpg()):

    http://public.activestate.com/cgi-bin/perlbrowse/p/29605


The problem is that OpenProcess() returns a HANDLE, but on
error it
returns NULL and not the usual INVALID_HANDLE_VALUE. I
assume the reason
for this is that at the kernel level, the
INVALID_HANDLE_VALUE bit
pattern is the same as the pseudo handle for the current
process.

The attached patch restores kill(0, $pid) behavior.

Cheers,
-Jan

Jan Dubois wrote:
> I broke the kill(0, $pid) behavior on Windows with
change 29605
> (the one implementing killpg()):
> 
>     http://public.activestate.com/cgi-bin/perlbrowse/p/29605

> 
> The problem is that OpenProcess() returns a HANDLE, but
on error it
> returns NULL and not the usual INVALID_HANDLE_VALUE. I
assume the reason
> for this is that at the kernel level, the
INVALID_HANDLE_VALUE bit
> pattern is the same as the pseudo handle for the
current process.
> 
> The attached patch restores kill(0, $pid) behavior.

Good catch! I guess there really ought to be a test for this
behaviour. 
I'll have a look later if nobody else beats me to it.

Anyway, applied as #30970. Thanks.

-- 

Steve Hay wrote:
> Jan Dubois wrote:
>> I broke the kill(0, $pid) behavior on Windows with
change 29605
>> (the one implementing killpg()):
>>
>>     http://public.activestate.com/cgi-bin/perlbrowse/p/29605

>>
>> The problem is that OpenProcess() returns a HANDLE,
but on error it
>> returns NULL and not the usual
INVALID_HANDLE_VALUE. I assume the reason
>> for this is that at the kernel level, the
INVALID_HANDLE_VALUE bit
>> pattern is the same as the pseudo handle for the
current process.
>>
>> The attached patch restores kill(0, $pid)
behavior.
> 
> Good catch! I guess there really ought to be a test for
this behaviour. 
> I'll have a look later if nobody else beats me to it.

I had a quick go at it. How does the attached t/op/kill.t
look?

Picking a PID that you know exists is easy, but how do you
pick a PID 
that you know doesn't exist? PID 0 currently doesn't exist
on my (WinXP) 
system, and it probably never does, but I've no idea how
portable that 
might be.

Also, are there any OSs that don't support kill(0, $pid) and
therefore 
need the tests skipping? perlport only mentions RISC OS so
perhaps a 
check for $^O eq 'riscos' will suffice?

-- 

Steve Hay wrote:
> Steve Hay wrote:
>> Jan Dubois wrote:
>>> I broke the kill(0, $pid) behavior on Windows
with change 29605
>>> (the one implementing killpg()):
>>>
>>>     http://public.activestate.com/cgi-bin/perlbrowse/p/29605

>>>
>>> The problem is that OpenProcess() returns a
HANDLE, but on error it
>>> returns NULL and not the usual
INVALID_HANDLE_VALUE. I assume the reason
>>> for this is that at the kernel level, the
INVALID_HANDLE_VALUE bit
>>> pattern is the same as the pseudo handle for
the current process.
>>>
>>> The attached patch restores kill(0, $pid)
behavior.
>>
>> Good catch! I guess there really ought to be a test
for this 
>> behaviour. I'll have a look later if nobody else
beats me to it.
> 
> I had a quick go at it. How does the attached
t/op/kill.t look?
> 
> Picking a PID that you know exists is easy, but how do
you pick a PID 
> that you know doesn't exist? PID 0 currently doesn't
exist on my (WinXP) 
> system, and it probably never does, but I've no idea
how portable that 
> might be.
> 
> Also, are there any OSs that don't support kill(0,
$pid) and therefore 
> need the tests skipping? perlport only mentions RISC OS
so perhaps a 
> check for $^O eq 'riscos' will suffice?
> 
> 
>
------------------------------------------------------------
------------
> 
> #!./perl
> 
> BEGIN {
>     chdir 't' if -d 't';
>     INC = '../lib';
>     require './test.pl';
> }
> 
> use strict;
> 
> plan tests => 2;
> 
> ok( kill(0, $$), 'kill(0, $pid) returns true if $pid
exists' );
> ok( !kill(0, 0), 'kill(0, $pid) returns false if $pid
does not exist' );

Speaking of kill... have you guys tried running kill(0,
undef) with 
certain versions of Perl? The earlier versions (5.8.2)
apparently killed 
the parent process instead of erroring out or something.

You just reminded me of that point.

-Garrett

On Tue, 17 Apr 2007, Steve Hay wrote:
> Picking a PID that you know exists is easy, but how do
you pick a PID
> that you know doesn't exist? PID 0 currently doesn't
exist on my
> (WinXP) system, and it probably never does, but I've no
idea how
> portable that might be.

PID 0 is used by the "System Idle Process".  It is
also used under POSIX
to indicate the current process group:

    http://www.opengroup.org/onlinepubs/009695399/f
unctions/kill.html

Note that with the current implementation of kill() and
killpg() we can
only kill() processes that are running under the same uid as
the perl
process itself. This limitation also applies to kill(0,
$pid), so even
though pid 0 may exist, you don't see it because it is owned
by the
system account.

This limitation is true even when you are running with
Administrator
rights. We can fix this by trying to acquire the
SeDebugPrivilege
privilege for the current perl process. I just didn't want
to have this
privilege turned on permanently. I'll try to come up with a
patch that
just turns it on for the OpenProcess() call and then turns
it off again.

As for finding a non-existing PID, I was thinking about just
running it
over a huge list of integers (1..30_000) and see if *all*
the processes
seem to exist, which seems rather unlikely.  Anyways, that
test would
have caught the specific failure I fixed with this patch.

Cheers,
-Jan

Garrett Cooper wrote:
>>> Jan Dubois wrote:
>>>> I broke the kill(0, $pid) behavior on
Windows with change 29605
>>>> (the one implementing killpg()):
>>>>
> 
> Speaking of kill... have you guys tried running kill(0,
undef) with 
> certain versions of Perl? The earlier versions (5.8.2)
apparently killed 
> the parent process instead of erroring out or
something.
> 
> You just reminded me of that point.

I can't reproduce anything like what you describe with
5.6.0, 5.6.1, any 
5.8.x or bleadperl. I tried running

perl -le "print kill(0, undef); print 'Hi'"

with each of those perls, and they all print 'Hi' okay. Is
this 
one-liner sufficient to show up the problem concerned?

I'm running on Windows XP. What OS have you seen this
problem on?

-- 

Jan Dubois wrote:
> On Tue, 17 Apr 2007, Steve Hay wrote:
>> Picking a PID that you know exists is easy, but how
do you pick a PID
>> that you know doesn't exist? PID 0 currently
doesn't exist on my
>> (WinXP) system, and it probably never does, but
I've no idea how
>> portable that might be.
> 
> PID 0 is used by the "System Idle Process". 


Doh! Yes, I see it in my Task manager now. I wonder why I
didn't notice 
it before. Not enough coffee, obviously.


> It is also used under POSIX
> to indicate the current process group:
> 
>     http://www.opengroup.org/onlinepubs/009695399/f
unctions/kill.html
> 
> Note that with the current implementation of kill() and
killpg() we can
> only kill() processes that are running under the same
uid as the perl
> process itself. This limitation also applies to kill(0,
$pid), so even
> though pid 0 may exist, you don't see it because it is
owned by the
> system account.
> 
> This limitation is true even when you are running with
Administrator
> rights. We can fix this by trying to acquire the
SeDebugPrivilege
> privilege for the current perl process. I just didn't
want to have this
> privilege turned on permanently. I'll try to come up
with a patch that
> just turns it on for the OpenProcess() call and then
turns it off again.

That would be useful. It would at least have saved me
kidding myself 
that there wasn't a PID 0 when there is!


> 
> As for finding a non-existing PID, I was thinking about
just running it
> over a huge list of integers (1..30_000) and see if
*all* the processes
> seem to exist, which seems rather unlikely.  Anyways,
that test would
> have caught the specific failure I fixed with this
patch.

The attached works OK for me (and fails OK if I revert your
fix). Is 
this all right now?

-- 

On Tue, 17 Apr 2007, Steve Hay wrote:
> Jan Dubois wrote:
>> PID 0 is used by the "System Idle
Process".
>
> Doh! Yes, I see it in my Task manager now. I wonder why
I didn't
> notice it before. Not enough coffee, obviously.

Maybe you didn't have "Show processes from all
users" selected?

> The attached works OK for me (and fails OK if I revert
your fix). Is
> this all right now?

Looks good to me.  Maybe you want to rename it to kill0.t,
so that
tests that actually *do* send a signal are in a separate
file?

Cheers,
-Jan

On Tue, 17 Apr 2007, Steve Hay wrote:
> Garrett Cooper wrote:
>> Speaking of kill... have you guys tried running
kill(0, undef) with
>> certain versions of Perl? The earlier versions
(5.8.2) apparently
>> killed the parent process instead of erroring out
or something.
>>
>> You just reminded me of that point.
>
> I can't reproduce anything like what you describe with
5.6.0,
> 5.6.1, any 5.8.x or bleadperl. I tried running
>
> perl -le "print kill(0, undef); print 'Hi'"
>
> with each of those perls, and they all print 'Hi' okay.
Is this one-
> liner sufficient to show up the problem concerned?

I assume Garrett was referring to this bug report:

    http://rt.perl.org/rt3/Public/Bug/Display.html?id=42101

I don't think this behavior is relevant to kill(0, $pid),
but only
to those that actually send a signal.  The bug was rejected,
as the
current behavior is standard POSIX functionality.

Cheers,
-Jan

Jan Dubois wrote:
> On Tue, 17 Apr 2007, Steve Hay wrote:
>> The attached works OK for me (and fails OK if I
revert your fix). Is
>> this all right now?
> 
> Looks good to me.  Maybe you want to rename it to
kill0.t, so that
> tests that actually *do* send a signal are in a
separate file?

Good idea. Submitted, renamed to kill0.t, as #30973.

--