[perl #116254] Win32 Perl's signal emulation permanently disables clib signals, then sets them, and excessive win32_signal_context() calls

On Mon Dec 31 00:53:30 2012, bulk88 wrote:
> This is a bug report for perl from bulk88@hotmail.com,
> generated with the help of perlbug 1.39 running under perl 5.17.7.
> 
> 
> -----------------------------------------------------------------
> [Please describe your issue here]
> 
> I noticed a redundant call to win32_signal_context from
> Perl_csighandler
> when doing a ctrl-c
> 
>
________________________________________________________________________________
>  >	perl517.dll!win32_signal_context()  Line 4168	C
>   	perl517.dll!Perl_csighandler(int sig=2)  Line 1310 + 0x5	C
>   	perl517.dll!do_raise(interpreter * my_perl=0x00346014, int sig=2)
> Line 2125 + 0x7	C
>   	perl517.dll!win32_ctrlhandler(unsigned long dwCtrlType=0)  Line
> 4205 + 0xb	C
>   	kernel32.dll!_CtrlRoutine@4()  + 0x118
>   	kernel32.dll!_BaseThreadStart@8()  + 0x37
>
________________________________________________________________________________
> 
> Yet TLS is guarenteed to have an interp by now because of
> win32_ctrlhandler also calling win32_signal_context().

I'm not sure that's true, do_raise() is also called from
win32_process_message()
which (if I understand the code) may be called in the context of a different
thread.

 Now, perl does
> register a sig handler with the CRT
...
> 
> but, from my research, a CRT sig handler will never be called, except
> through maybe raise(), which win32 perl does not link with (I checked
> import table of perl517.dll), the first time signal() is called in the
> process, the CRT sets a flag inside itself that it itself called
> SetConsoleCtrlHandler, it will never call it again. When Perl removes
> the CRT handler, and installs its own, it has disabled CRT signals for
> the rest of the process's run. Yet perl continues to register sig
> handlers with the CRT even though they never will be called by the OS.
> 
> relevant code is
>
http://perl5.git.perl.org/perl.git/blob/1feab43956f936b2526693e4394a9653fcea6079:/win32/win32.c#l4570
> 
> I feel something is redundant here or should be removed. I am not sure
> what. If Perl_csighandler can only be called with raise (same thread),
> or from win32_ctrlhandler (random OS thread), it needs a normal dTHX,
> not a dTHXa(PERL_GET_SIG_CONTEXT);. Maybe Perl should stop registering
> Perl_csighandler with the CRT with signal() since that handler will
> never be called from the OS, or Perl.

Perhaps it's to allow interoperability with XS modules that call raise().

I can't think of any other reason.

Perhaps that's why Perl_sys_inter_init() calls signal() - so XS calling
signal() won't interfere with perl's initialization of the CTRL-C
processing flag.

> 
> Trying to synthesis a ctrl-c with kill didn't work (
> http://perlmonks.org/?node_id=1010891 not sure if this will work on
> Unix
> or not). On some signums, it killed the perl process (NUM05) in
>
http://perl5.git.perl.org/perl.git/blob/1feab43956f936b2526693e4394a9653fcea6079:/win32/win32.c#l1231
> , on others the %SIG was never called (like BREAK) (IDK why yet on
> BREAK).

What brought me to this ticket was this issue.

I was attemptting to write a signal handler test for #85104, but kill
"INT", $pid wasn't working from a separate process.

I did end up managing to generate a signal caught by
$SIG{INT}/$SIG{BREAK}, but using a C program that calls
GenerateConsoleCtrlEvent() with a dwProcessGroupId of 0, which I can't
see a way of doing from perl code (kill 'INT', 0 fails because it can't
open pid 0.)

Supplying the pid of the process to GenerateConsoleCtrlEvent() never
worked (and failed when called from a different console.)

This appears to be a Win32 issue (ie. Windows is strange...)

Testing done on Windows 7.

> Also Perl_sighandler calls win32_signal_context, yet can only be
> called
> from Perl_csighandler or Perl_despatch_signals, both of which already
> called win32_signal_context (Perl_csighandler) or always have TLS set
> up
> correctly (Perl_despatch_signals).

See my note about win32_process_message() above.

> Perl's Win32 emulated signals will never be posix compatible, but they
> shouldn't do a bad job at what limited capability they have.  I'd like
> some comments before I try changing any of this code and writing a
> patch.

Tests are probably the hard part.

Tony


---
via perlbug:  queue: perl5 status: new
https://rt.perl.org:443/rt3/Ticket/Display.html?id=116254

• [perl #116254] Win32 Perl's signal emulation permanently disables clib signals, then sets them, and excessive win32_signal_context() calls by Tony Cook via RT
• [perl #116254] Win32 Perl's signal emulation permanently disablesclib signals, then sets them, and excessive win32_signal_context() calls by James E Keenan via RT