Bug #102709 for PAR-Packer: Unable to handle SIG interrupts

Wed Mar 11 20:17:22 2015 gabeak [...] gmail.com - Ticket created

Subject:	Unable to handle SIG interrupts
Date:	Wed, 11 Mar 2015 17:17:12 -0700
To:	bug-PAR-Packer [...] rt.cpan.org
From:	Gabriel Khwaja <gabeak [...] gmail.com>

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.

Thu Mar 12 03:56:58 2015 RSCHUPP [...] cpan.org - Correspondence added

Am 2015-03-11 20:17:22, gabeak@gmail.com schrieb: Show quoted text

> 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

Thu Mar 12 03:56:59 2015 The RT System itself - Status changed from 'new' to 'open'

Fri Jul 03 23:12:58 2015 ZDM [...] cpan.org - Correspondence added

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

Subject:

patch

Download patch
application/octet-stream 472b

Message body not shown because it is not plain text.

Sat Jul 04 12:43:51 2015 RSCHUPP [...] cpan.org - Correspondence added

On 2015-07-03 23:12:58, ZDM wrote: Show quoted text

> We need to ignore SIGINT in main process under windows.

Show quoted text

> Here is the patch:

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

Mon Jul 06 01:18:54 2015 ZDM [...] cpan.org - Correspondence added

On Sat Jul 04 12:43:51 2015, RSCHUPP wrote: Show quoted text

> On 2015-07-03 23:12:58, ZDM wrote:

> > We need to ignore SIGINT in main process under windows.

>

> > Here is the patch:

> > 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.

Mon Jul 06 02:30:57 2015 ZDM [...] cpan.org - Correspondence added

On Sat Jul 04 12:43:51 2015, RSCHUPP wrote: Show quoted text

> On 2015-07-03 23:12:58, ZDM wrote:

> > We need to ignore SIGINT in main process under windows.

>

> > Here is the patch:

> > 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.

Mon Jul 06 05:35:18 2015 RSCHUPP [...] cpan.org - Correspondence added

On 2015-07-06 01:18:54, ZDM wrote: Show quoted text

> Do you see the patch code?

Yes. Please use a unified diff next time. Show quoted text

> 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). Show quoted text

> 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

Wed Jul 08 00:57:23 2015 ZDM [...] cpan.org - Correspondence added

On Mon Jul 06 05:35:18 2015, RSCHUPP wrote: Show quoted text

> On 2015-07-06 01:18:54, ZDM wrote:

> > Do you see the patch code?

> > Yes. Please use a unified diff next time. >

> > 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). >

> > 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.)

Wed Jul 08 09:41:49 2015 RSCHUPP [...] cpan.org - Correspondence added

Hi, sorry for the late response, I'm trying to catch up on open bugs: On 2015-03-11 20:17:22, gabeak@gmail.com wrote: Show quoted text

> 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

Wed Jul 08 13:24:01 2015 ZDM [...] cpan.org - Correspondence added

On Wed Jul 08 09:41:49 2015, RSCHUPP wrote: Show quoted text

> Hi, > > sorry for the late response, I'm trying to catch up on open bugs: > > On 2015-03-11 20:17:22, gabeak@gmail.com wrote:

> > 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.

Thu Jul 09 04:51:00 2015 RSCHUPP [...] cpan.org - Correspondence added

Am 2015-07-08 13:24:01, ZDM schrieb: Show quoted text

> 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

Thu Jul 09 11:10:58 2015 ZDM [...] cpan.org - Correspondence added

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.

Mon Jul 13 17:16:15 2015 ZDM [...] cpan.org - Correspondence added

Hi, Roderich. Topic starter, seems, will never answer. Do you plan to include this changes and close the issue?

Fri Jul 17 04:57:08 2015 ZDM [...] cpan.org - Correspondence added

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?

Fri Jul 17 05:25:23 2015 RSCHUPP [...] cpan.org - Correspondence added

On 2015-07-17 04:57:08, ZDM wrote: Show quoted text

> 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. Show quoted text

> 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. Show quoted text

> Another thing - if I use something like this: > 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. Show quoted text

> 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

Fri Jul 17 07:09:38 2015 ZDM [...] cpan.org - Correspondence added

On Fri Jul 17 05:25:23 2015, RSCHUPP wrote: Show quoted text

> On 2015-07-17 04:57:08, ZDM wrote:

> > 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. >

> > 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. >

> > Another thing - if I use something like this: > > 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. Show quoted text

> 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. Show quoted text

> > 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? Show quoted text

> Cheers, Roderich

Fri Jul 17 07:46:57 2015 ZDM [...] cpan.org - Correspondence added

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.

Fri Jul 17 08:04:17 2015 RSCHUPP [...] cpan.org - Correspondence added

On 2015-07-17 07:09:38, ZDM wrote: Show quoted text

> - 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. Show quoted text

> 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

Sat Jul 18 02:04:58 2015 ZDM [...] cpan.org - Correspondence added

Please, look at examples in attachments. 1.pl - source script. 1.exe - packed with current PAR::Packer version. 1-patched.exe - packed with patched PAR::Packer version.

Subject:

1-patched.exe

Download 1-patched.exe
application/octet-stream 2.5m

Message body not shown because it is not plain text.

Subject:

1.exe

Download 1.exe
application/octet-stream 2.5m

Message body not shown because it is not plain text.

Subject:

1.pl

#!/usr/bin/env perl package main v0.1.0; my $i; $SIG{INT} = sub { print "--- SIGINT\n"; exit if ++$i > 2; return; }; while (1) { print "ALIVE\n"; sleep 1; } 1; __END__