develooper Front page | perl.perl5.porters | Postings from August 2013

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

Thread Next
Tony Cook via RT
August 20, 2013 07:02
[perl #116254] Win32 Perl's signal emulation permanently disables clib signals, then sets them, and excessive win32_signal_context() calls
Message ID:
On Mon Dec 31 00:53:30 2012, bulk88 wrote:
> This is a bug report for perl from,
> 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
which (if I understand the code) may be called in the context of a different

 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
> 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 (
> not sure if this will work on
> Unix
> or not). On some signums, it killed the perl process (NUM05) in
> , on others the %SIG was never called (like BREAK) (IDK why yet on

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.


via perlbug:  queue: perl5 status: new

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About