kill($sig, $pid) does not work as documented on Win32

[p5pRT]

Migrated from rt.perl.org#36108 (status was 'open')

Searchable as RT36108$

[p5pRT]

From @steve-m-hay

Created by @steve-m-hay

The following program

use Config;
my @​signals = split / /, $Config{sig_name};
foreach my $signal (@​signals) {
  system qq[$^X -e "kill $signal, \$\$; sleep 1"];
  print "$signal\t\$? >> 8 = ", $? >> 8, "\n";
}

outputs this on Win32

ZERO $? >> 8 = 0
HUP $? >> 8 = 1
INT $? >> 8 = 0
QUIT $? >> 8 = 0
ILL $? >> 8 = 4
NUM05 $? >> 8 = 5
NUM06 $? >> 8 = 6
NUM07 $? >> 8 = 7
FPE $? >> 8 = 8
KILL $? >> 8 = 9
NUM10 $? >> 8 = 10
SEGV $? >> 8 = 11
NUM12 $? >> 8 = 12
PIPE $? >> 8 = 13
ALRM $? >> 8 = 14
TERM $? >> 8 = 0
NUM16 $? >> 8 = 16
NUM17 $? >> 8 = 17
NUM18 $? >> 8 = 18
NUM19 $? >> 8 = 19
CHLD $? >> 8 = 20
BREAK $? >> 8 = 0
ABRT $? >> 8 = 22
STOP $? >> 8 = 23
NUM24 $? >> 8 = 24
CONT $? >> 8 = 25
CLD $? >> 8 = 20

but according to the perlport manpage kill($sig, $pid) should make
the process identified by $pid exit with status $sig.

Therefore, it appears that kill($sig, $pid) does not behave correctly
where $sig is one of

INT
QUIT
TERM
BREAK
CLD

Perl Info

Flags:
    category=core
    severity=medium

Site configuration information for perl v5.8.6:

Configured by steveh at Tue Dec  7 11:33:40 2004.

Summary of my perl5 (revision 5 version 8 subversion 6) configuration:
  Platform:
    osname=MSWin32, osvers=4.0, archname=MSWin32-x86-perlio
    uname=''
    config_args='undef'
    hint=recommended, useposix=true, d_sigaction=undef
    usethreads=undef use5005threads=undef useithreads=undef 
usemultiplicity=undef
    useperlio=define d_sfio=undef uselargefiles=undef usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=y, bincompat5005=undef
  Compiler:
    cc='cl', ccflags ='-nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 
-D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT  -DPERL_DEBUGGING_MSTATS 
-DUSE_PERLIO -DPERL_MSVCRT_READFIX',
    optimize='-MD -Zi -DNDEBUG -O1',
    cppflags='-DWIN32'
    ccversion='', gccversion='', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', 
lseeksize=4
    alignbytes=8, prototype=define
  Linker and Libraries:
    ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf  
-libpath:"C:\perl5\lib\CORE"  -machine:x86'
    libpth=C:\PROGRA~1\MICROS~2\VC98\lib
    libs=  oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib  
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib  
netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib  version.lib 
odbc32.lib odbccp32.lib msvcrt.lib
    perllibs=  oldnames.lib kernel32.lib user32.lib gdi32.lib 
winspool.lib  comdlg32.lib advapi32.lib shell32.lib ole32.lib 
oleaut32.lib  netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib  
version.lib odbc32.lib odbccp32.lib msvcrt.lib
    libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib
    gnulibc_version='undef'
  Dynamic Linking:
    dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' '
    cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug 
-opt:ref,icf  -libpath:"C:\perl5\lib\CORE"  -machine:x86'

Locally applied patches:
    


@INC for perl v5.8.6:
    C:/perl5/lib
    C:/perl5/site/lib
    .


Environment for perl v5.8.6:
    HOME (unset)
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    
PATH=C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\perl5\bin;C:\Program 
Files\Perforce
    PERL_BADLANG (unset)
    SHELL (unset)



------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.

[p5pRT]

From @schwern

On Fri, Jun 03, 2005 at 08​:51​:36AM -0000, Steve Hay wrote​:

Therefore, it appears that kill($sig, $pid) does not behave correctly
where $sig is one of

INT
QUIT
TERM
BREAK
CLD

What does the equivalent C program do? Just checking to see if its Perl
or Win32.

--
Michael G Schwern schwern@​pobox.com http​://www.pobox.com/~schwern
'All anyone gets in a mirror is themselves,' she said. 'But what you
gets in a good gumbo is everything.'
  -- "Witches Abroad" by Terry Prachett

[p5pRT]

The RT System itself - Status changed from 'new' to 'open'

[p5pRT]

From @steve-m-hay

Michael G Schwern wrote​:

On Fri, Jun 03, 2005 at 08​:51​:36AM -0000, Steve Hay wrote​:

Therefore, it appears that kill($sig, $pid) does not behave correctly
where $sig is one of

INT
QUIT
TERM
BREAK
CLD

What does the equivalent C program do? Just checking to see if its Perl
or Win32.

Good question, and in trying to write to equivalent C program I've
realised that Win32 doesn't actually have kill() in its CRT!

win32/win32.c handles it in win32_kill() like this​:

  switch(sig) {
  case 0​:
  /* "Does process exist?" use of kill */
  retval = 0;
  break;
  case 2​:
  if (GenerateConsoleCtrlEvent(CTRL_C_EVENT,pid))
  retval = 0;
  break;
  case SIGBREAK​:
  case SIGTERM​:
  if (GenerateConsoleCtrlEvent(CTRL_BREAK_EVENT,pid))
  retval = 0;
  break;
  default​: /* For now be backwards compatible with perl5.6 */
  case 9​:
  if (TerminateProcess(hProcess, sig))
  retval = 0;
  break;
  }

which I guess mostly explains the behaviour I reported​:
GenerateConsoleCtrlEvent() causes the control handler functions of
processes in the target group to be called, so they are free to exit
with whatever status they choose in response to such events.

So INT, TERM and BREAK are simply documented wrongly in perlport. I'm
not sure why QUIT and CLD didn't work right, though.

---

Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses​: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.

[p5pRT]

From @jandubois

On Fri, 03 Jun 2005, Michael G Schwern wrote​:

On Fri, Jun 03, 2005 at 08​:51​:36AM -0000, Steve Hay wrote​:

Therefore, it appears that kill($sig, $pid) does not behave correctly
where $sig is one of

INT

This is signal 2 in the code below (SIGINT is not defined on Windows).

QUIT

Perl maps SIGQUIT to SIGBREAK on Windows.

TERM
BREAK
CLD

Perl maps SIGCLD to SIGCHLD on Windows.

What does the equivalent C program do? Just checking to see if its Perl
or Win32.

It is the Perl implementation (from win32/win32.c in win32_kill()​:

  else {
alien_process​:
  retval = -1;
  hProcess = OpenProcess(PROCESS_ALL_ACCESS, TRUE,
  (IsWin95() ? -pid : pid));
  if (hProcess) {
  switch(sig) {
  case 0​:
  /* "Does process exist?" use of kill */
  retval = 0;
  break;
  case 2​:
  if (GenerateConsoleCtrlEvent(CTRL_C_EVENT,pid))
  retval = 0;
  break;
  case SIGBREAK​:
  case SIGTERM​:
  if (GenerateConsoleCtrlEvent(CTRL_BREAK_EVENT,pid))
  retval = 0;
  break;
  default​: /* For now be backwards compatible with perl5.6 */
  case 9​:
  if (TerminateProcess(hProcess, sig))
  retval = 0;
  break;
  }
  }
  CloseHandle(hProcess);
  if (retval == 0)
  return 0;
  }
  }

Cheers,
-Jan

[p5pRT]

From nick@ing-simmons.net

Steve Hay <steve.hay@​uk.radan.com> writes​:

Good question, and in trying to write to equivalent C program I've
realised that Win32 doesn't actually have kill() in its CRT!

win32/win32.c handles it in win32_kill() like this​:

   switch\(sig\) \{
   case 0​:
       /\* "Does process exist?" use of kill \*/
       retval = 0;
               break;
   case 2​:
       if \(GenerateConsoleCtrlEvent\(CTRL\_C\_EVENT\,pid\)\)
       retval = 0;
       break;
           case SIGBREAK​:
           case SIGTERM​:
               if \(GenerateConsoleCtrlEvent\(CTRL\_BREAK\_EVENT\,pid\)\)
                  retval = 0;
               break;
   default​: /\* For now be backwards compatible with perl5\.6 \*/
           case 9​:
       if \(TerminateProcess\(hProcess\, sig\)\)
       retval = 0;
               break;
   \}

which I guess mostly explains the behaviour I reported​:

And at least part of that coding was mine.
I was trying to cleanup Win32's signals/events at the time
and then (possibly as a result of this work!) my NT partition on that
machine went AWOL and I lost enthusiasm.

Corrupting partitions aside, I think there is still scope for
Win32 to do better at signals - particularly between a perl parent
and its pseudo-fork()ed children.

GenerateConsoleCtrlEvent() causes the control handler functions of
processes in the target group to be called, so they are free to exit
with whatever status they choose in response to such events.

So INT, TERM and BREAK are simply documented wrongly in perlport. I'm
not sure why QUIT and CLD didn't work right, though.

------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses​: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.