[rt.cpan.org #102709] Unable to handle SIG interrupts

[Gabriel Khwaja via RT]

Wed Mar 11 20:17:22 2015: Request 102709 was acted upon.
Transaction: Ticket created by ***@gmail.com
Queue: PAR-Packer
Subject: Unable to handle SIG interrupts
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@gmail.com
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=102709 >


Windows 7 64 Bit
Activestate Perl v5.18.4 built for MSWin32-x86-multi-thread-64int
PAR-Packer version 1.025

I just used pp to package my app to exe. It's running well however in my
app I catch the $SIG{'INT'} event (ctrl-c) so that I can do some clean up
steps before ending. However, since pp actually creates a parent exe and
this exe does not ignore ctrl-c events, the parent closes but my app keeps
running but it doesn't run properly without the parent app and does not
exit.

I was previously using perl2exe and everything was behaving as expected. I
switched to pp since perl2exe support stopped at perl 5.16.

I think the pp "parent" exe should be catching signals and send them over
to the child app - and it should not close, otherwise, the app is not
behaving as intended.

[Roderich Schupp via RT]

Thu Mar 12 03:56:58 2015: Request 102709 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: Unable to handle SIG interrupts
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@gmail.com
Status: new
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=102709 >

Post by Gabriel Khwaja via RT
I think the pp "parent" exe should be catching signals and send them over
to the child app - and it should not close, otherwise, the app is not
behaving as intended.

Your analyis is correct - on Windows, we us spawnvpe to start the custom
perl interpreter that actually runs your original program, so the
boot process stays around until the spawned process exits (on *nix we
use execvp which just "replaces" the boot process, so no problem there).

I don't have a Windows machine anymore, hence can't fix this. If you want
to try yourself, the code is in myldr/boot.c at the end (inside the
#ifdef WIN32 block). This is in plain C (but specific to Windows) and has nothing to do with Perl.

Cheers, Roderich

[Dmytro Zagashev via RT]

Fri Jul 03 23:12:58 2015: Request 102709 was acted upon.
Transaction: Correspondence added by ZDM
Queue: PAR-Packer
Subject: Unable to handle SIG interrupts
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=102709 >


We need to ignore SIGINT in main process under windows.

Here is the patch:

diff -r PAR-Packer-1.025/myldr/boot.c PAR-Packer-1.025-orig/myldr/boot.c
219,228d218
< #include <signal.h>
<
< void sigintHandler(int sig_num) {
< /* Reset handler to catch SIGINT next time. Refer http://en.cppreference.com/w/c/program/signal */
< signal(SIGINT, sigintHandler);
< }
<
< /* Set the SIGINT (Ctrl-C) signal handler to sigintHandler Refer http://en.cppreference.com/w/c/program/signal */
< signal(SIGINT, sigintHandler);
<

Tested under:

strawberry-perl-5.20.2-x64
strawberry-perl-5.22.0
strawberry-perl-5.22.0-x64

[Roderich Schupp via RT]

Sat Jul 04 12:43:51 2015: Request 102709 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: Unable to handle SIG interrupts
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=102709 >

Post by Dmytro Zagashev via RT
We need to ignore SIGINT in main process under windows.

First, this isn't Windows specific (makes no sense when not on Windows.
Second, it isn't the correct solution to the original problem.

Cheers, Roderich

[Dmytro Zagashev via RT]

Mon Jul 06 01:18:54 2015: Request 102709 was acted upon.
Transaction: Correspondence added by ZDM
Queue: PAR-Packer
Subject: Unable to handle SIG interrupts
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=102709 >

Post by Roderich Schupp via RT

Post by Dmytro Zagashev via RT
We need to ignore SIGINT in main process under windows.

First, this isn't Windows specific (makes no sense when not on Windows.
Second, it isn't the correct solution to the original problem.
Cheers, Roderich

Do you see the patch code?

1. It is only for windows.

2. It solves the problem completely. It prevent parent process to exit by SIGINT. When CTRL+C pressed - windows send SIGINT to process group. Parent process ignore this signal, but child process catch and process and can exit or do something else. Parent process exit only after child has finished.

[Dmytro Zagashev via RT]

Mon Jul 06 02:30:57 2015: Request 102709 was acted upon.
Transaction: Correspondence added by ZDM
Queue: PAR-Packer
Subject: Unable to handle SIG interrupts
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=102709 >

Post by Roderich Schupp via RT

Post by Dmytro Zagashev via RT
We need to ignore SIGINT in main process under windows.

First, this isn't Windows specific (makes no sense when not on Windows.
Second, it isn't the correct solution to the original problem.
Cheers, Roderich

Why you say, that this is not correct solution?

The problem is, that under windows the parent process exited on CTRL+C (and, also, do not perform temp dir cleanup, if PAR was created with --clean option) immediately, without waiting until child process exit.

Parent process under windows should exit only after child has been finished. The proper solution - is to ignore SIGINT in parent process.

This patch solves this and do not affect linux code.

[Roderich Schupp via RT]

Mon Jul 06 05:35:18 2015: Request 102709 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: Unable to handle SIG interrupts
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=102709 >

Post by Dmytro Zagashev via RT
Do you see the patch code?

Yes. Please use a unified diff next time.

Post by Dmytro Zagashev via RT
1. It is only for windows.

This restriction isn't in your patch (or I can't tell from your patch because of
missing context, see above).

Post by Dmytro Zagashev via RT
2. It solves the problem completely. It prevent parent process to exit
by SIGINT. When CTRL+C pressed - windows send SIGINT to process group.

Can you cite some reference for this, preferably from MSDN.

Also, why do you re-arm the signal handler - no modern system should need that,
you should use sigaction anyway.

Cheers, Roderich

[Dmytro Zagashev via RT]

Wed Jul 08 00:57:23 2015: Request 102709 was acted upon.
Transaction: Correspondence added by ZDM
Queue: PAR-Packer
Subject: Unable to handle SIG interrupts
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=102709 >

Post by Roderich Schupp via RT

Post by Dmytro Zagashev via RT
Do you see the patch code?

Yes. Please use a unified diff next time.

Post by Dmytro Zagashev via RT
1. It is only for windows.

This restriction isn't in your patch (or I can't tell from your patch
because of
missing context, see above).

Post by Dmytro Zagashev via RT
2. It solves the problem completely. It prevent parent process to
exit
by SIGINT. When CTRL+C pressed - windows send SIGINT to process
group.

Can you cite some reference for this, preferably from MSDN.
Also, why do you re-arm the signal handler - no modern system should
need that,
you should use sigaction anyway.
Cheers, Roderich

Here is the more correct solution and simple:

# include <signal.h>
signal(SIGINT, SIG_IGN);

1. Previously signal was re-armed in handler, because signal call drop handler to the default. This is not needed if we use SIG_IGN;

2. sigaction is too complex and not needed if we just want to ignore signal;

3. About CTRL+C under windows:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682541%28v=vs.85%29.aspx

By default, these signals are passed to all console processes that are attached to the console. (Detached processes are not affected.)

[Roderich Schupp via RT]

Wed Jul 08 09:41:49 2015: Request 102709 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: Unable to handle SIG interrupts
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=102709 >


Hi,

Post by Gabriel Khwaja via RT
I just used pp to package my app to exe. It's running well however in my
app I catch the $SIG{'INT'} event (ctrl-c) so that I can do some clean up
steps before ending. However, since pp actually creates a parent exe and
this exe does not ignore ctrl-c events, the parent closes but my app keeps
running but it doesn't run properly without the parent app and does not
exit.

What do you mean when you say "my app ... doesn't run properly and does not exit"? Also, is this a "command line" program or does it have a GUI (i.e. you packed it using "pp --gui ...")?
Can you cook up a minimal example that shows the problem?

Cheers, Roderich

[Dmytro Zagashev via RT]

Wed Jul 08 13:24:01 2015: Request 102709 was acted upon.
Transaction: Correspondence added by ZDM
Queue: PAR-Packer
Subject: Unable to handle SIG interrupts
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=102709 >

Post by Roderich Schupp via RT
Hi,

Post by Gabriel Khwaja via RT
I just used pp to package my app to exe. It's running well however
in my
app I catch the $SIG{'INT'} event (ctrl-c) so that I can do some
clean up
steps before ending. However, since pp actually creates a parent exe
and
this exe does not ignore ctrl-c events, the parent closes but my app
keeps
running but it doesn't run properly without the parent app and does
not
exit.

What do you mean when you say "my app ... doesn't run properly and
does not exit"? Also, is this a "command line" program or does it have
a GUI (i.e. you packed it using "pp --gui ...")?
Can you cook up a minimal example that shows the problem?
Cheers, Roderich

Under windows parent process is only spawn child, waiting until child exited and perform cleanup (if was packed with --clean).

This is obvious, that parent should not exit on CTRL+C. No matter, has child process GUI or this is just command line app.

[Roderich Schupp via RT]

Thu Jul 09 04:51:00 2015: Request 102709 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: Unable to handle SIG interrupts
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=102709 >

Post by Dmytro Zagashev via RT
This is obvious, that parent should not exit on CTRL+C. No matter, has
child process GUI or this is just command line app.

No, it's not obvious at all.
BTW, thanks for the MSDN reference. If his "app" is a command line app ("console application" in Windows lingo), then - according to
this article - SIGINT should be deliverd to both parent and child.
But then what is his actual problem (aside from the missing
cleanup of extracted files if packed with --clean? Is the SIGINT
handler in the child not called? And what does "it doesn't run properly without the parent app and does not exit" mean?
OTOH if his "app" is a GUI application, there's no console window,
so what does Ctrl-C mean here?
I think this is a typical case of an "XY problem", so I need
a minimal example to see what's actually going on, otherwise
I'll close this bug report.

Cheers, Roderich

[Dmytro Zagashev via RT]

Thu Jul 09 11:10:58 2015: Request 102709 was acted upon.
Transaction: Correspondence added by ZDM
Queue: PAR-Packer
Subject: Unable to handle SIG interrupts
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=102709 >


1. According to MSDN - CTRL+C have a special behavior only for console applications. For GUI - developer should manually catch and process corresponded windows message (CTRL+C is not generates SIGINT for the gui apps).

2. About "it doesn't run properly without the parent app and does not exit", etc...

Child still run properly, can receive signals, print something to console, but parent has been exited - so console become free for user input. I can type and execute another console command. But child process still attached to this console instance and his output become mixed with new commands, etc...

Another thing - if I use something like this:

print 'Press ENTER to continue...';
<STDIN>;

this not works. I think - this is because console catch <ENTER> key press and process it without sending to the child process. Or maybe STDIN for child process become closed.

All this problems are not observed if parent process is attached to the console.

[Dmytro Zagashev via RT]

Mon Jul 13 17:16:15 2015: Request 102709 was acted upon.
Transaction: Correspondence added by ZDM
Queue: PAR-Packer
Subject: Unable to handle SIG interrupts
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=102709 >


Hi, Roderich.

Topic starter, seems, will never answer.

Do you plan to include this changes and close the issue?

[Dmytro Zagashev via RT]

Fri Jul 17 04:57:08 2015: Request 102709 was acted upon.
Transaction: Correspondence added by ZDM
Queue: PAR-Packer
Subject: Unable to handle SIG interrupts
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=102709 >


Roderich,

We can go other way.

Can you give an example, when parent process under windows should exit on CTRL+C without waiting for a child and do not perform standard cleanup operations and makes zombie from the child process?

I don't see any such cases.

This is a typical software bug, and I watched him since using parl under windows. This bug is not critical, but makes software behavior unexpected.

Really, I don't understand, why you do not want to fix this? What are you waiting for?

[Roderich Schupp via RT]

Fri Jul 17 05:25:23 2015: Request 102709 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: Unable to handle SIG interrupts
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=102709 >

Post by Dmytro Zagashev via RT
Really, I don't understand, why you do not want to fix this? What are
you waiting for?

Time to think this thru. You have not convinced me yet, see below.
And it's my time and my disgression how I spend it.

Post by Dmytro Zagashev via RT
Can you give an example, when parent process under windows should exit
on CTRL+C without waiting for a child and do not perform standard
cleanup operations and makes zombie from the child process?

What are you talking about, there are no zombies here.

Post by Dmytro Zagashev via RT
print 'Press ENTER to continue...';
<STDIN>;

I managed to get hold of an old laptop running Windows XP and I can't reproduce
this here: If I Ctrl-C the above example at the prompt, both the parent
and the child get killed, so I don't see the point.
If the script has set up a SIGINT handler, it is executed. Yeah, the cleanup
in the parent isn't run in this case, but it isn't on *nix either.
Also, there's no harm in leaving some temp files around.

Post by Dmytro Zagashev via RT
This is a typical software bug, and I watched him since using parl
under windows. This bug is not critical, but makes software behavior
unexpected.

Nope, _ignoring_ SIGINT is unexpected behaviour.

Cheers, Roderich

[Dmytro Zagashev via RT]

Fri Jul 17 07:09:38 2015: Request 102709 was acted upon.
Transaction: Correspondence added by ZDM
Queue: PAR-Packer
Subject: Unable to handle SIG interrupts
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=102709 >

Post by Roderich Schupp via RT

Post by Dmytro Zagashev via RT
Really, I don't understand, why you do not want to fix this? What are
you waiting for?

Time to think this thru. You have not convinced me yet, see below.
And it's my time and my disgression how I spend it.

Post by Dmytro Zagashev via RT
Can you give an example, when parent process under windows should
exit
on CTRL+C without waiting for a child and do not perform standard
cleanup operations and makes zombie from the child process?

What are you talking about, there are no zombies here.

Post by Dmytro Zagashev via RT
print 'Press ENTER to continue...';
<STDIN>;

I managed to get hold of an old laptop running Windows XP and I can't
reproduce
this here: If I Ctrl-C the above example at the prompt, both the
parent
and the child get killed, so I don't see the point.
If the script has set up a SIGINT handler, it is executed. Yeah, the
cleanup
in the parent isn't run in this case, but it isn't on *nix either.

- Why you speak about unix? This bug is on windows only. And patch only for windows and do not affect unix code.

Post by Roderich Schupp via RT
Also, there's no harm in leaving some temp files around.

- What is the option "--clean" for, if it does not work? Ok, this is not really serious disadvantage, except, if user will run the program frequently. In anyway, clearing garbage - is a good style.

Post by Roderich Schupp via RT

Post by Dmytro Zagashev via RT
This is a typical software bug, and I watched him since using parl
under windows. This bug is not critical, but makes software behavior
unexpected.

Nope, _ignoring_ SIGINT is unexpected behaviour.

- Ignoring SIGINT in parent is unexpected? Why? This is the main question.

All significant code is executed in child process. Including signals processing. Parent should only wait, until child has been exited and perform cleanup, if needed. I do not see any other functionality in myldr/boot.c.

This is unexpected, if user press CTRL+C and parent process will be finished, but child process will keep running in background.

Any user will think, that process finished completely, but this is not true.

Or you think, that, some users are expect this?

Why you are disagree with this obvious thing? Look into your code, what proofs you are looking for?

Post by Roderich Schupp via RT
Cheers, Roderich

[Dmytro Zagashev via RT]

Fri Jul 17 07:46:57 2015: Request 102709 was acted upon.
Transaction: Correspondence added by ZDM
Queue: PAR-Packer
Subject: Unable to handle SIG interrupts
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=102709 >


Also, this is not the "XY problem". This is a real fully-qualified bug. That leads to the invalid behavior, when program should not exit on SIGINT immediately, but, for example, finish currently running transactions (what can take a lot of time).

Proposed solution resolves this bug completely and do not affect other parts of code.

[Roderich Schupp via RT]

Fri Jul 17 08:04:17 2015: Request 102709 was acted upon.
Transaction: Correspondence added by RSCHUPP
Queue: PAR-Packer
Subject: Unable to handle SIG interrupts
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: ***@gmail.com
Status: open
Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=102709 >

Post by Dmytro Zagashev via RT
- What is the option "--clean" for, if it does not work? Ok, this is
not really serious disadvantage, except, if user will run the program
frequently.

I don't know what you mean by this.

Post by Dmytro Zagashev via RT
This is unexpected, if user press CTRL+C and parent process will be
finished, but child process will keep running in background.

You keep repeating this, but this _not_ what I see.
Please present an example that I can reproduce.
Otherwise this discussion ends here and I'll close this bug without action.

Cheers, Roderich