-
Notifications
You must be signed in to change notification settings - Fork 540
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
process group kill on Win32 broken in 5.17.2, regression 5.18 #13595
Comments
From @bulk88Created by @bulk88Patch c2fd40c DllExport int
win32_kill(int pid, int sig)
{ On 5.16 and older, when running the test script, sig is -, and pid +. errno = EINVAL;
return -1;
} Callstacks from the 2nd system proc in test script.
Another problem is that this removal in the patch is probably - APPLY_TAINT_PROPER();
-#ifdef HAS_KILLPG
- if (PerlProc_killpg(proc,val)) /* BSD */
-#else
- if (PerlProc_kill(-proc,val)) /* SYSV */
-#endif
- tot--; Win32 Perl defines PerlProcKillpg as this int
PerlProcKillpg(struct IPerlProc* piPerl, int pid, int sig)
{
return win32_kill(pid, -sig);
} About the test script included, both system()ed perls are launched and How this regression was found? This report came from trying to eliminate Perl Info
|
From @bulk88kill.pl$pid = system(1, $^X.' -e "sleep 500"');
system(1, $^X.' -e "print kill(-9, '.$pid.') ? \"kill sucessful\n\" : \"couldnt kill\n\";'); |
From @bulk88Perl Info
C:\>perl "C:\Documents and Settings\Administrator\Desktop\kill.pl" C:\>kill sucessful C:\> |
From @steve-m-hayThank you for finding this! It's bugged me for ages that Clearly I should have shouted because this is a nasty regression. This one really needs fixing. Should it even be a blocker for 5.20? |
The RT System itself - Status changed from 'new' to 'open' |
From @bulk88On Wed Feb 12 01:07:10 2014, shay wrote:
I will be very clear, this ticket isn't about that watchdog hang. Fixing kill() process group will not unhang that test.
Yes because the feature worked in 5.12 to 5.16. IDK if it existed in < 5.12. I can't fix this because it is a POSIX, and I IDK enough in that area. I do not understand the complaint in #112990 and solution in there. Therefore my opinion is to git revert that commit, but that probably is not the right solution. If I do try to code it, I will probably break non-Win32 builds. Therefore I didn't offer a patch and I only supplied a test script and the details in the OP. -- |
From @iabynOn Sat, Feb 22, 2014 at 01:50:12AM -0800, bulk88 via RT wrote:
I've pushed a fix as smoke-me/davem/killpg. I haven't of course tested it Are you in a position to contribute Win32-specific tests for this? -- |
From @bulk88On Sun Feb 23 05:57:55 2014, davem wrote:
Yes. It will be a day or 2 for me to try it. I'm not sure whether to add the test to t/op/kill0.t or t/win32/system.t. -- |
From @bulk88While writing a test for this, I discovered another bug or issue in Win32 PG kill. PG kill is supposed to return the number of processes "signaled" (is this a synonym for "killed" on Win32 platform?) per perldoc
My testing shows the retval in PP of PG kill in 5.12.2 is always 1. from win32_kill()if (child >= 0) {
if (my_kill(pid, sig)) {<<<<<<<<<<<<kill count lost
DWORD exitcode = 0;
if (GetExitCodeProcess(w32_child_handles[child], &exitcode) &&
exitcode != STILL_ACTIVE)
{
remove_dead_process(child);
}
return 0;
}
} Perl_applyif (val < 0) {
val = -val;
while (++mark <= sp) {
I32 proc;
if (!(SvIOK(*mark) || SvNOK(*mark) || looks_like_number(*mark)))
Perl_croak(aTHX_ "Can't kill a non-numeric process ID");
proc = SvIV(*mark);
APPLY_TAINT_PROPER();
#ifdef HAS_KILLPG
if (PerlProc_killpg(proc,val)) /* BSD */ <<<<<<<<<<<<<no way to return kill count, but posix killpg doesn't return process count, just error code
#else
if (PerlProc_kill(-proc,val)) /* SYSV */
#endif Is this something to be fixed or it is correct behavior that you can't tell how many processes were in the group from a kill on a PG? -- |
From @iabynOn Tue, Feb 25, 2014 at 05:10:33PM -0800, bulk88 via RT wrote:
I think the perl docs are misleading. It's not supposed to indicate kill $SIG, $proc1, $proc2, $no_such_process; returns 2. -- |
From @bulk88On Sun Feb 23 05:57:55 2014, davem wrote:
Test patch attached. Not fully smoked on Win32, but "perl harness op/kill0.t" passes. I'm not sure if the unix file perms on the new file in the patch are correct since my git is Win32. -- |
From @bulk880001-RT-121230-create-tests-for-process-group-kill-on-Win.patchFrom 7062d2991e08b2b516db88450d4337d83910d462 Mon Sep 17 00:00:00 2001
From: bulk88 <bulk88@hotmail.com>
Date: Wed, 26 Feb 2014 17:31:18 -0500
Subject: [PATCH] RT #121230, create tests for process group kill on Win32
---
t/op/kill0.t | 41 ++++++++++++++++++++++++++++++++++++++++-
t/op/kill0_child | 9 +++++++++
2 files changed, 49 insertions(+), 1 deletions(-)
create mode 100644 t/op/kill0_child
diff --git a/t/op/kill0.t b/t/op/kill0.t
index d3ef8f7..4012761 100644
--- a/t/op/kill0.t
+++ b/t/op/kill0.t
@@ -13,8 +13,9 @@ BEGIN {
}
use strict;
+use Config;
-plan tests => 6;
+plan tests => 9;
ok( kill(0, $$), 'kill(0, $pid) returns true if $pid exists' );
@@ -50,3 +51,41 @@ for my $case ( @bad_pids ) {
$x =~ /(\d+)/;
ok(eval { kill 0, $1 }, "can kill a number string in a magic variable");
}
+
+SKIP: {
+ skip 'custom process group kill() only on Win32', 3 if ($^O ne 'MSWin32');
+ #create 2 child processes, an outer one created by kill0.t, and an inner one
+ #created by outer this allows the test to fail if only the outer one was
+ #killed, since the inner will stay around and eventually print failed and
+ #out of sequence TAP to harness
+ unlink('killchildstarted');
+ die q|can't unlink| if -e 'killchildstarted';
+ eval q|END{unlink('killchildstarted');}|;
+ my $pid = system(1, $^X, 'op/kill0_child', 'killchildstarted');
+ die 'PID is 0' if !$pid;
+ while( ! -e 'killchildstarted') {
+ sleep 1; #a sleep 0 with $i++ will takes ~160 iterations here
+ }
+ #ways to break this test manually, change '-KILL' to 'KILL', change $pid to a
+ #bogus number
+ is(kill('-KILL', $pid), 1, 'process group kill, named signal');
+
+ my ($i, %signo, @signame, $sig_name) = 0;
+ ($sig_name = $Config{sig_name}) || die "No signals?";
+ foreach my $name (split(' ', $sig_name)) {
+ $signo{$name} = $i;
+ $signame[$i] = $name;
+ $i++;
+ }
+ ok(scalar keys %signo > 1 && exists $signo{KILL}, '$Config{sig_name} parsed correctly');
+ die q|A child proc wasn't killed and did cleanup on its own| if ! -e 'killchildstarted';
+ unlink('killchildstarted');
+ die q|can't unlink| if -e 'killchildstarted';
+ #no END block, done earlier
+ $pid = system(1, $^X, 'op/kill0_child', 'killchildstarted');
+ die 'PID is 0' if !$pid;
+ while( ! -e 'killchildstarted') {
+ sleep 1; #a sleep 0 with $i++ will takes ~160 iterations here
+ }
+ is(kill(-$signo{KILL}, $pid), 1, 'process group kill, numeric signal');
+}
diff --git a/t/op/kill0_child b/t/op/kill0_child
new file mode 100644
index 0000000..c3d5eb2
--- /dev/null
+++ b/t/op/kill0_child
@@ -0,0 +1,9 @@
+#$ARGV[0] is filename used to notify parent .t perl proc that all PIDs are
+#started in the process tree
+#number 9999/9998 is eye catching
+system(1, $^X, '-e', 'sleep 5; print qq|not ok 9999 - inner child process wasn\'t killed\n|;');
+system('echo outer child started > "'.$ARGV[0].'"');
+sleep 5;
+#execution won't be reached if test successful
+print "not ok 9998 - outer child process wasn\'t killed\n";
+unlink($ARGV[0]);
--
1.7.9.msysgit.0
|
From @bulk88On Wed Feb 26 06:04:15 2014, davem wrote:
Patch for POD. -- |
From @bulk880001-clarify-kill-s-POD.patchFrom 8a0503965f4d6e9165156115692d8f7a8338495c Mon Sep 17 00:00:00 2001
From: bulk88 <bulk88@hotmail.com>
Date: Wed, 26 Feb 2014 18:14:24 -0500
Subject: [PATCH] clarify kill's POD
part of RT #121230
---
pod/perlfunc.pod | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/pod/perlfunc.pod b/pod/perlfunc.pod
index 14c5171..8a3aaab 100644
--- a/pod/perlfunc.pod
+++ b/pod/perlfunc.pod
@@ -3218,7 +3218,7 @@ X<kill> X<signal>
Sends a signal to a list of processes. Returns the number of
processes successfully signaled (which is not necessarily the
-same as the number actually killed).
+same as the number actually killed) from the list of processes supplied.
$cnt = kill 'HUP', $child1, $child2;
kill 'KILL', @goners;
--
1.7.9.msysgit.0
|
From @bulk88On Wed Feb 26 14:40:54 2014, bulk88 wrote:
This patch is broken. Fails manifest.t and I forgot perldelta.pod. I have manifest.t fixed, but I am having a perldelta.pod and podcheck.t problem that is being addressed in a separate ML thread. So wait until I have a new patch. -- |
From @bulk88On Wed Feb 26 23:06:03 2014, bulk88 wrote:
New patch attached. -- |
From @bulk880001-RT-121230-create-tests-for-process-group-kill-on-Win.patchFrom dc146462729d13b3038d9a58ac6291bc2e09f77f Mon Sep 17 00:00:00 2001
From: bulk88 <bulk88@hotmail.com>
Date: Thu, 27 Feb 2014 04:00:43 -0500
Subject: [PATCH] RT #121230, create tests for process group kill on Win32
---
MANIFEST | 3 ++-
pod/perldelta.pod | 9 +++++++--
t/op/kill0.t | 41 ++++++++++++++++++++++++++++++++++++++++-
t/op/kill0_child | 9 +++++++++
4 files changed, 58 insertions(+), 4 deletions(-)
create mode 100644 t/op/kill0_child
diff --git a/MANIFEST b/MANIFEST
index 9fcb518..e7ab59a 100644
--- a/MANIFEST
+++ b/MANIFEST
@@ -5238,7 +5238,8 @@ t/op/index.t See if index works
t/op/index_thr.t See if index works in another thread
t/op/int.t See if int works
t/op/join.t See if join works
-t/op/kill0.t See if kill(0, $pid) works
+t/op/kill0_child Process tree script that is kill()ed
+t/op/kill0.t See if kill works
t/op/kvaslice.t See if index/value array slices work
t/op/kvhslice.t See if key/value hash slices work
t/op/lc.t See if lc, uc, lcfirst, ucfirst, quotemeta work
diff --git a/pod/perldelta.pod b/pod/perldelta.pod
index ab26873..f298d47 100644
--- a/pod/perldelta.pod
+++ b/pod/perldelta.pod
@@ -319,11 +319,16 @@ and compilation changes or changes in portability/compatibility. However,
changes within modules for platforms should generally be listed in the
L</Modules and Pragmata> section.
+=head3 Win32
+
=over 4
-=item XXX-some-platform
+=item *
-XXX
+Killing a process tree with L<perlfunc/kill> and a negative signal, was broken
+starting in 5.17.2. In this bug, C<kill> always returned 0 for a negative
+signal even for valid PIDs, and no processes were terminated. This has been
+fixed [perl #121230].
=back
diff --git a/t/op/kill0.t b/t/op/kill0.t
index d3ef8f7..4012761 100644
--- a/t/op/kill0.t
+++ b/t/op/kill0.t
@@ -13,8 +13,9 @@ BEGIN {
}
use strict;
+use Config;
-plan tests => 6;
+plan tests => 9;
ok( kill(0, $$), 'kill(0, $pid) returns true if $pid exists' );
@@ -50,3 +51,41 @@ for my $case ( @bad_pids ) {
$x =~ /(\d+)/;
ok(eval { kill 0, $1 }, "can kill a number string in a magic variable");
}
+
+SKIP: {
+ skip 'custom process group kill() only on Win32', 3 if ($^O ne 'MSWin32');
+ #create 2 child processes, an outer one created by kill0.t, and an inner one
+ #created by outer this allows the test to fail if only the outer one was
+ #killed, since the inner will stay around and eventually print failed and
+ #out of sequence TAP to harness
+ unlink('killchildstarted');
+ die q|can't unlink| if -e 'killchildstarted';
+ eval q|END{unlink('killchildstarted');}|;
+ my $pid = system(1, $^X, 'op/kill0_child', 'killchildstarted');
+ die 'PID is 0' if !$pid;
+ while( ! -e 'killchildstarted') {
+ sleep 1; #a sleep 0 with $i++ will takes ~160 iterations here
+ }
+ #ways to break this test manually, change '-KILL' to 'KILL', change $pid to a
+ #bogus number
+ is(kill('-KILL', $pid), 1, 'process group kill, named signal');
+
+ my ($i, %signo, @signame, $sig_name) = 0;
+ ($sig_name = $Config{sig_name}) || die "No signals?";
+ foreach my $name (split(' ', $sig_name)) {
+ $signo{$name} = $i;
+ $signame[$i] = $name;
+ $i++;
+ }
+ ok(scalar keys %signo > 1 && exists $signo{KILL}, '$Config{sig_name} parsed correctly');
+ die q|A child proc wasn't killed and did cleanup on its own| if ! -e 'killchildstarted';
+ unlink('killchildstarted');
+ die q|can't unlink| if -e 'killchildstarted';
+ #no END block, done earlier
+ $pid = system(1, $^X, 'op/kill0_child', 'killchildstarted');
+ die 'PID is 0' if !$pid;
+ while( ! -e 'killchildstarted') {
+ sleep 1; #a sleep 0 with $i++ will takes ~160 iterations here
+ }
+ is(kill(-$signo{KILL}, $pid), 1, 'process group kill, numeric signal');
+}
diff --git a/t/op/kill0_child b/t/op/kill0_child
new file mode 100644
index 0000000..c3d5eb2
--- /dev/null
+++ b/t/op/kill0_child
@@ -0,0 +1,9 @@
+#$ARGV[0] is filename used to notify parent .t perl proc that all PIDs are
+#started in the process tree
+#number 9999/9998 is eye catching
+system(1, $^X, '-e', 'sleep 5; print qq|not ok 9999 - inner child process wasn\'t killed\n|;');
+system('echo outer child started > "'.$ARGV[0].'"');
+sleep 5;
+#execution won't be reached if test successful
+print "not ok 9998 - outer child process wasn\'t killed\n";
+unlink($ARGV[0]);
--
1.7.9.msysgit.0
|
From @HugmeirOn Thu, Feb 27, 2014 at 10:07 AM, bulk88 via RT
Better to use 5.18.0 here -- the vast majority of users have no reason to
^ how thoroughly was this tested? <10 second waits tend to fail on VMs |
From @bulk88On Thu Feb 27 03:01:28 2014, Hugmeir wrote:
Will revise. But I need a response to my comments about the next comment first.
Ran it a couple dozen times repeatedly breaking it by giving bogus signals, + signals, and fake pids and made sure harness failed as a not ok fail or out of sequence fail. Originally kill0.t did a "sleep 1;" to wait for the outer and inner procs to start. You dont want to kill the outer before it starts the inner proc which is what I encountered if the kill was sent with no delay after the system(). I then realized this is begging for a race condition and subsequent test fail in a VM with rough host timeslicing. I then switched to using the disk file. Win32::Event isn't core http://search.cpan.org/~cjm/Win32-IPC-1.09/lib/Win32/Event.pm . So I can't use that as IPC. It also is XS. Sleeping a very high number near infinity sounds like a bad idea to me and a way to hang a smoker if something goes wrong (and what will go wrong can't be predicted). I picked 5 secs because it seems like a good balance between waiting the kill0.t to get back its timeslice and do the kill, vs I/O blocking harness since kill0.t failed to kill the 2 child procs (future or manual breakage), and now harness is waiting 4 seconds until the 2 child procs close their stdio handles, and probably (assuming a lack of random kernel memory corruption and being a couple ms away from a panic/bsod) will write "not ok" to the tap stream. Also I picked 5 instead of 3 secs because of a possibility of future parallel testing on Win32. -- |
From @iabynOn Sun, Feb 23, 2014 at 01:57:23PM +0000, Dave Mitchell wrote:
Now in blead as -- |
From @bulk88On Thu Feb 27 09:02:49 2014, bulk88 wrote:
I don't think I will get a response. So it stays at 5 seconds and a new patch mentioning 5.18.0 instead of 5.17.2 is attached. -- |
From @bulk880001-RT-121230-create-tests-for-process-group-kill-on-Win.patchFrom d37c11f7b2b728856f89ce7f8afc7665f6922d8a Mon Sep 17 00:00:00 2001
From: bulk88 <bulk88@hotmail.com>
Date: Fri, 28 Feb 2014 23:56:54 -0500
Subject: [PATCH] RT #121230, create tests for process group kill on Win32
---
MANIFEST | 3 ++-
pod/perldelta.pod | 9 +++++++--
t/op/kill0.t | 41 ++++++++++++++++++++++++++++++++++++++++-
t/op/kill0_child | 9 +++++++++
4 files changed, 58 insertions(+), 4 deletions(-)
create mode 100644 t/op/kill0_child
diff --git a/MANIFEST b/MANIFEST
index 9fcb518..e7ab59a 100644
--- a/MANIFEST
+++ b/MANIFEST
@@ -5238,7 +5238,8 @@ t/op/index.t See if index works
t/op/index_thr.t See if index works in another thread
t/op/int.t See if int works
t/op/join.t See if join works
-t/op/kill0.t See if kill(0, $pid) works
+t/op/kill0_child Process tree script that is kill()ed
+t/op/kill0.t See if kill works
t/op/kvaslice.t See if index/value array slices work
t/op/kvhslice.t See if key/value hash slices work
t/op/lc.t See if lc, uc, lcfirst, ucfirst, quotemeta work
diff --git a/pod/perldelta.pod b/pod/perldelta.pod
index ab26873..1f413ff 100644
--- a/pod/perldelta.pod
+++ b/pod/perldelta.pod
@@ -319,11 +319,16 @@ and compilation changes or changes in portability/compatibility. However,
changes within modules for platforms should generally be listed in the
L</Modules and Pragmata> section.
+=head3 Win32
+
=over 4
-=item XXX-some-platform
+=item *
-XXX
+Killing a process tree with L<perlfunc/kill> and a negative signal, was broken
+starting in 5.18.0. In this bug, C<kill> always returned 0 for a negative
+signal even for valid PIDs, and no processes were terminated. This has been
+fixed [perl #121230].
=back
diff --git a/t/op/kill0.t b/t/op/kill0.t
index d3ef8f7..4012761 100644
--- a/t/op/kill0.t
+++ b/t/op/kill0.t
@@ -13,8 +13,9 @@ BEGIN {
}
use strict;
+use Config;
-plan tests => 6;
+plan tests => 9;
ok( kill(0, $$), 'kill(0, $pid) returns true if $pid exists' );
@@ -50,3 +51,41 @@ for my $case ( @bad_pids ) {
$x =~ /(\d+)/;
ok(eval { kill 0, $1 }, "can kill a number string in a magic variable");
}
+
+SKIP: {
+ skip 'custom process group kill() only on Win32', 3 if ($^O ne 'MSWin32');
+ #create 2 child processes, an outer one created by kill0.t, and an inner one
+ #created by outer this allows the test to fail if only the outer one was
+ #killed, since the inner will stay around and eventually print failed and
+ #out of sequence TAP to harness
+ unlink('killchildstarted');
+ die q|can't unlink| if -e 'killchildstarted';
+ eval q|END{unlink('killchildstarted');}|;
+ my $pid = system(1, $^X, 'op/kill0_child', 'killchildstarted');
+ die 'PID is 0' if !$pid;
+ while( ! -e 'killchildstarted') {
+ sleep 1; #a sleep 0 with $i++ will takes ~160 iterations here
+ }
+ #ways to break this test manually, change '-KILL' to 'KILL', change $pid to a
+ #bogus number
+ is(kill('-KILL', $pid), 1, 'process group kill, named signal');
+
+ my ($i, %signo, @signame, $sig_name) = 0;
+ ($sig_name = $Config{sig_name}) || die "No signals?";
+ foreach my $name (split(' ', $sig_name)) {
+ $signo{$name} = $i;
+ $signame[$i] = $name;
+ $i++;
+ }
+ ok(scalar keys %signo > 1 && exists $signo{KILL}, '$Config{sig_name} parsed correctly');
+ die q|A child proc wasn't killed and did cleanup on its own| if ! -e 'killchildstarted';
+ unlink('killchildstarted');
+ die q|can't unlink| if -e 'killchildstarted';
+ #no END block, done earlier
+ $pid = system(1, $^X, 'op/kill0_child', 'killchildstarted');
+ die 'PID is 0' if !$pid;
+ while( ! -e 'killchildstarted') {
+ sleep 1; #a sleep 0 with $i++ will takes ~160 iterations here
+ }
+ is(kill(-$signo{KILL}, $pid), 1, 'process group kill, numeric signal');
+}
diff --git a/t/op/kill0_child b/t/op/kill0_child
new file mode 100644
index 0000000..c3d5eb2
--- /dev/null
+++ b/t/op/kill0_child
@@ -0,0 +1,9 @@
+#$ARGV[0] is filename used to notify parent .t perl proc that all PIDs are
+#started in the process tree
+#number 9999/9998 is eye catching
+system(1, $^X, '-e', 'sleep 5; print qq|not ok 9999 - inner child process wasn\'t killed\n|;');
+system('echo outer child started > "'.$ARGV[0].'"');
+sleep 5;
+#execution won't be reached if test successful
+print "not ok 9998 - outer child process wasn\'t killed\n";
+unlink($ARGV[0]);
--
1.7.9.msysgit.0
|
From @bulk88On Fri Feb 28 20:59:15 2014, bulk88 wrote:
Bump. -- |
From @iabynOn Fri, Feb 28, 2014 at 08:59:15PM -0800, bulk88 via RT wrote:
Thanks, applied as af728ca. I also took the libery of cleaning the code commit 4c0e595 tidy up kill0.t and kill0_child -- |
From @iabynOn Wed, Feb 26, 2014 at 03:16:25PM -0800, bulk88 via RT wrote:
Thanks. However, I ended up rewording it again as follows, with 12733a0, -Sends a signal to a list of processes. Returns the number of -- |
From @bulk88On Mon Mar 17 09:40:43 2014, davem wrote:
Everything is fine in that except 1 thing. Why replace the single quotes with double quotes for the sake of using double quotes? I've always assume double quotes take longer for the compiler to parse than single quotes, and using double quotes without knowing why leads to a larger change of unintended code execution/interpolation. -- |
From @iabynOn Mon, Mar 17, 2014 at 02:43:56PM -0700, bulk88 via RT wrote:
The difference in parsing time between single and double quotes strings is So I went for readability. IMO, "that's all" q|that's all| since the '|' character in perl isn't normally associated with string The choice of single verses double-quoted is debatable. It can cause q|that's all, $person| while someone modifying my code might do "that's all you get for $100" In either case, if the programmer doesn't check the quotedness of string -- |
From @demerphqOn 18 March 2014 13:03, Dave Mitchell <davem@iabyn.com> wrote:
IMO there is no point in worrying about these kind of things unless Yves |
From @TuxOn Tue, 18 Mar 2014 13:15:11 +0100, demerphq <demerphq@gmail.com> wrote:
And not even then. I benched it years ago on several machines, and all Let's just be consistent! More interesting would be to check if "foo: ".$foo.", bar: ".$bar is -- |
From @bulk88On Mon Mar 17 09:40:43 2014, davem wrote:
http://www.nntp.perl.org/group/perl.daily-build.reports/2014/03/msg159824.html the test is failing on Geroge smoker. I fetched a new blead and reran it on my machine and ../t/op/kill0.t passes. The kill() calls fail. What is unusual is that there is no "not ok 9999" or out of sequence reports in the report, so I presume the child procs never got CPU time even though they got PIDs or were actually killed on an OS level and something went wrong in the win32_killpg. The only idea I have right now is to increase the sleep 5 to 15 in http://perl5.git.perl.org/perl.git/blob/HEAD:/t/op/kill0_child . -- |
From @bulk88On Fri Mar 21 13:58:09 2014, bulk88 wrote:
I sort of (no CC no make, tests that use either fail catasfrical (not a word, i kno), M::B hangs forever on nearly every test) reran blead on a win2k machine. nothing kill related failed and the kill .ts didnt fail. So its something specific to a VM or the george software stack. -- |
From @rjbsbulk88 requested that this be marked a 5.20.0 blocker, but I'm not entirely sure what issue remains on the ticket, on which discussion has sort of meandered. (a) is this still a blocker candidate? -- |
From @iabynOn Mon, Mar 24, 2014 at 07:19:37AM -0700, Ricardo SIGNES via RT wrote:
The bug has been fixed, but the just-added test is failing on George's So we either need to get the test fixed, or backout the new test. -- |
From @bulk88Dave Mitchell wrote:
5.18 maint backport is also a possibility since this is a regression for |
From @steve-m-hayOn 24 March 2014 21:58, bulk88 <bulk88@hotmail.com> wrote:
Sorry, I had assumed that I couldn't reproduce either this since my So I built with USE_MULTI=undef USE_ITHREADS=undef USE_IMP_SYS=undef C:\Dev\Git\perl\t>..\perl harness -v op\kill0.t Test Summary Report op/kill0.t (Wstat: 0 Tests: 9 Failed: 2) I don't have time to look right now, but will dig deeper tomorrow... |
From @bulk88On Mon Mar 24 16:09:44 2014, shay wrote:
Reproduced. C:\perl519\src\t>..\perl -I..\lib op/kill0.t C:\perl519\src\t> I will investigate. -- |
From @bulk88On Mon Mar 24 17:11:39 2014, bulk88 wrote:
Perl's win32 killpg in win32.c doesn't match the POSIX expectations that Perl_apply has for killpg. When PERL_IMPLICIT_SYS/perlhost.h/PerlProcKillpg is removed, then Perl_apply directly calls killpg which follows Win32 coding style, not POSIX coding style. With PERL_IMPLICIT_SYS, PerlProcKillpg calls win32_kill which calls my_kill which calls killpg. I plan on renaming killpg to my_killpg, then create a win32_killpg that follows POSIXese, and untangle the spaghetti. -- |
From @bulk88On Mon Mar 24 18:00:26 2014, bulk88 wrote:
Code already written but I can't make test it ATM. Will take a day or 2 to get to posting the patch, need to file another Perl RT or CPAN RT bug first since make test fails badly for me due to a /cpan module. -- |
From @bulk88On Tue Mar 25 22:52:13 2014, bulk88 wrote:
kill0.t passed for me on no-threads perl with this patch. I couldn't make harness finish due to a different bug. -- |
From @bulk880001-fix-killpg-on-Win32-to-meet-posix-expectations-for-k.patchFrom 5916dd7a8033a4d89aa7f6d7e52a718e96a7fa4d Mon Sep 17 00:00:00 2001
From: Daniel Dragan <bulk88@hotmail.com>
Date: Thu, 27 Mar 2014 03:37:03 -0400
Subject: [PATCH] fix killpg on Win32, to meet posix expectations for killpg
On Win32 Perls built without PERL_IMPLICIT_SYS, killpg from win32.c was
directly called by Perl_apply, yet killpg's return value had Win32
behavior, not POSIX behavior. Modify killpg token to have same meaning as
PerlProcKillpg/PerlProc_killpg has on PERL_IMPLICIT_SYS builds. Use a
macro rather than create a win32_killpg C function since win32_killpg would
be nothing but a call to win32_kill anyways. win32_kill contains the Win32
to POSIX semantics conversion code. Rename old killpg to my_killpg since
it has no use outside of win32.c. The psuedo-PID code in win32_kill also
played a factor in not writing a separate win32_killpg that calls
my_killpg. This fix is tested by kill0.t passing on
no-PERL_IMPLICIT_SYS builds.
[perl #121230]
---
pod/perldelta.pod | 8 ++++++++
win32/win32.c | 11 +++++++----
win32/win32.h | 1 -
win32/win32iop.h | 5 +++++
4 files changed, 20 insertions(+), 5 deletions(-)
diff --git a/pod/perldelta.pod b/pod/perldelta.pod
index 358aea3..aa7e1ce 100644
--- a/pod/perldelta.pod
+++ b/pod/perldelta.pod
@@ -316,6 +316,14 @@ a bug in which the timeout monitor used for tests could not be cancelled once
the test completes, and the full timeout period elapsed before running the next
test file.
+On a Perl built without psuedo-fork (psuedo-fork builds were not affected by
+this bug), probably since prcess tree kill feature was implemented on Win32,
+killing a process tree with L<perlfunc/kill> and a negative signal, resulted
+in kill inverting the returned value. This ment successfully killing
+1 process tree PID returned 0, and also passing 2 invalid PID, returned 2.
+This has been corrected so the documented behavior for return values for kill
+executes. [perl #121230]
+
=back
=head1 Internal Changes
diff --git a/win32/win32.c b/win32/win32.c
index dda951b..6dc6ec1 100644
--- a/win32/win32.c
+++ b/win32/win32.c
@@ -139,6 +139,7 @@ static int do_spawnvp_handles(int mode, const char *cmdname,
static long find_pid(pTHX_ int pid);
static void remove_dead_process(long child);
static int terminate_process(DWORD pid, HANDLE process_handle, int sig);
+static int my_killpg(int pid, int sig);
static int my_kill(int pid, int sig);
static void out_of_memory(void);
static char* wstr_to_str(const wchar_t* wstr);
@@ -1250,8 +1251,9 @@ terminate_process(DWORD pid, HANDLE process_handle, int sig)
return 0;
}
-int
-killpg(int pid, int sig)
+/* returns number of processes killed */
+static int
+my_killpg(int pid, int sig)
{
HANDLE process_handle;
HANDLE snapshot_handle;
@@ -1271,7 +1273,7 @@ killpg(int pid, int sig)
if (Process32First(snapshot_handle, &entry)) {
do {
if (entry.th32ParentProcessID == (DWORD)pid)
- killed += killpg(entry.th32ProcessID, sig);
+ killed += my_killpg(entry.th32ProcessID, sig);
entry.dwSize = sizeof(entry);
}
while (Process32Next(snapshot_handle, &entry));
@@ -1282,6 +1284,7 @@ killpg(int pid, int sig)
return killed;
}
+/* returns number of processes killed */
static int
my_kill(int pid, int sig)
{
@@ -1289,7 +1292,7 @@ my_kill(int pid, int sig)
HANDLE process_handle;
if (sig < 0)
- return killpg(pid, -sig);
+ return my_killpg(pid, -sig);
process_handle = OpenProcess(PROCESS_TERMINATE, FALSE, pid);
/* OpenProcess() returns NULL on error, *not* INVALID_HANDLE_VALUE */
diff --git a/win32/win32.h b/win32/win32.h
index 3d1655a..e109939 100644
--- a/win32/win32.h
+++ b/win32/win32.h
@@ -322,7 +322,6 @@ extern gid_t getegid(void);
extern int setuid(uid_t uid);
extern int setgid(gid_t gid);
extern int kill(int pid, int sig);
-extern int killpg(int pid, int sig);
#ifndef USE_PERL_SBRK
extern void *sbrk(ptrdiff_t need);
# define HAS_SBRK_PROTO
diff --git a/win32/win32iop.h b/win32/win32iop.h
index 11d4219..246375f 100644
--- a/win32/win32iop.h
+++ b/win32/win32iop.h
@@ -448,6 +448,11 @@ END_EXTERN_C
# undef kill
#endif
#define kill win32_kill
+#ifdef UNDER_CE
+# undef killpg
+#endif
+#define killpg(pid, sig) win32_kill(pid, -(sig))
+
#ifdef UNDER_CE
# undef opendir
--
1.7.9.msysgit.0
|
From @steve-m-hayThanks, applied as 721b267. (A full "nmake test 2>nul" with no Does this complete #121230 now? I.e. should the ticket be closed now? |
From @bulk88Lets wait until the George smoker delivers a new report. I see nothing since Mar 23 on the Win2k smoker http://www.nntp.perl.org/group/perl.daily-build.reports/ . -- |
From @bulk88Mar 23 is still the last smoke. I think it hung. Its been 12 days with no response. |
From @bulk88George the human responded about problems with the process group kill code in Message-ID: <alpine.LFD.2.11.1404222133090.31829@ein.m-l.org> . Its not showing up on nttp.perl.org yet so I can't offer a link. -- |
From @Smylersbulk88 via RT writes:
It's http://nntp.perl.org/group/perl.perl5.porters/214650 For future reference, all P5P emails contain a link to their own web X-List-Archive: <http://nntp.perl.org/group/perl.perl5.porters/214650> Smylers |
From @demerphqOn 18 March 2014 13:46, H.Merijn Brand <h.m.brand@xs4all.nl> wrote:
Well no, when the string becomes long it starts being interesting to When I checked last Perl has non-linear and degrading performance In practice unless the string is quite long (hundreds to thousands of Yves -- |
From @rjbs* Smylers <Smylers@stripey.com> [2014-04-23T05:47:50]
<jawdrop> You're my hero of the day! -- |
From @greergaArchives of the logs and reports are always on my web site: Yes, the process group kill code is probably nuking the Win32 blead As for the reports, I had a hard drive go bad in the RAID5 so I shut the 1: http://m-l.org/~perl/smoke/perl/win32/blead/status -- |
From @steve-m-hayOn 23 April 2014 14:17, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
This was news to me too, and would have saved a delay in updating the Thanks! |
From @iabynOn Wed, Apr 23, 2014 at 01:34:21PM +0200, demerphq wrote:
The double-quoted parsing code is very inefficient. It does a lot of -- |
From @maukeOn Thu Mar 27 11:02:51 2014, bulk88 wrote:
What's the status of this ticket? It's listed in perl5200delta. |
The original issue seems to have been patched. Tests were also put in and appear to still be in blead. I don't see anything remaining to do in this case. |
Migrated from rt.perl.org#121230 (status was 'open')
Searchable as RT121230$
The text was updated successfully, but these errors were encountered: