[rt.cpan.org #102709] Unable to handle SIG interrupts
Wed Jan 13 05:47:41 2021: 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: gab...@gmail.com Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=102709 > Cleaning out old tickets...
[rt.cpan.org #102709] Unable to handle SIG interrupts
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: gab...@gmail.com Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=102709 > On 2015-07-17 07:09:38, ZDM wrote: > - 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. > 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
[rt.cpan.org #102709] Unable to handle SIG interrupts
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: gab...@gmail.com Status: open Ticket 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.
[rt.cpan.org #102709] Unable to handle SIG interrupts
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: gab...@gmail.com Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=102709 > On Fri Jul 17 05:25:23 2015, RSCHUPP wrote: > 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...'; > > ; > > 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. > 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. > > 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? > Cheers, Roderich
[rt.cpan.org #102709] Unable to handle SIG interrupts
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: gab...@gmail.com Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=102709 > 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...'; > ; 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. > 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
[rt.cpan.org #102709] Unable to handle SIG interrupts
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: gab...@gmail.com Status: open Ticket 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?
[rt.cpan.org #102709] Unable to handle SIG interrupts
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: gab...@gmail.com Status: open Ticket 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?
[rt.cpan.org #102709] Unable to handle SIG interrupts
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: gab...@gmail.com Status: open Ticket 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...'; ; this not works. I think - this is because console catch 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.
[rt.cpan.org #102709] Unable to handle SIG interrupts
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: gab...@gmail.com
Status: open
Ticket https://rt.cpan.org/Ticket/Display.html?id=102709 >
Am 2015-07-08 13:24:01, ZDM schrieb:
> 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
[rt.cpan.org #102709] Unable to handle SIG interrupts
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: gab...@gmail.com
Status: open
Ticket https://rt.cpan.org/Ticket/Display.html?id=102709 >
On Wed Jul 08 09:41:49 2015, RSCHUPP wrote:
> Hi,
>
> sorry for the late response, I'm trying to catch up on open bugs:
>
> On 2015-03-11 20:17:22, gab...@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.
[rt.cpan.org #102709] Unable to handle SIG interrupts
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: gab...@gmail.com
Status: open
Ticket https://rt.cpan.org/Ticket/Display.html?id=102709 >
Hi,
sorry for the late response, I'm trying to catch up on open bugs:
On 2015-03-11 20:17:22, gab...@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
[rt.cpan.org #102709] Unable to handle SIG interrupts
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: gab...@gmail.com Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=102709 > On Mon Jul 06 05:35:18 2015, RSCHUPP wrote: > 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(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.)
[rt.cpan.org #102709] Unable to handle SIG interrupts
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: gab...@gmail.com Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=102709 > 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
[rt.cpan.org #102709] Unable to handle SIG interrupts
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: gab...@gmail.com Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=102709 > On Sat Jul 04 12:43:51 2015, RSCHUPP wrote: > 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.
[rt.cpan.org #102709] Unable to handle SIG interrupts
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: gab...@gmail.com Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=102709 > On Sat Jul 04 12:43:51 2015, RSCHUPP wrote: > 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.
[rt.cpan.org #102709] Unable to handle SIG interrupts
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: gab...@gmail.com Status: open Ticket https://rt.cpan.org/Ticket/Display.html?id=102709 > 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
[rt.cpan.org #102709] Unable to handle SIG interrupts
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: gab...@gmail.com
Status: open
Ticket 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
<
< 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
patch
Description: Binary data
[rt.cpan.org #102709] Unable to handle SIG interrupts
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: gab...@gmail.com Status: new Ticket https://rt.cpan.org/Ticket/Display.html?id=102709 > Am 2015-03-11 20:17:22, gab...@gmail.com schrieb: > 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
[rt.cpan.org #102709] Unable to handle SIG interrupts
Wed Mar 11 20:17:22 2015: Request 102709 was acted upon.
Transaction: Ticket created by gab...@gmail.com
Queue: PAR-Packer
Subject: Unable to handle SIG interrupts
Broken in: (no value)
Severity: (no value)
Owner: Nobody
Requestors: gab...@gmail.com
Status: new
Ticket 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.
