Setting $! during DESTROY clobbers exit value #15152
Comments
From @FGasperCreated by @FGasperThe docs say: If an uncaught exception results in interpreter exit, the exit exit ... however, the below shows an example of where $! is not truthy, --------------- { package Finally; sub new { bless [ $_[1] ] } sub DESTROY { $_[0]->[0]->() } Per the documentation, Perl should be exiting 255, not 0. Perl Info |
From @FGasperThis affects every Perl version I have tried. |
From [Unknown Contact. See original ticket]This affects every Perl version I have tried. |
From @tonycozOn Tue Jan 26 21:33:43 2016, felipe@felipegasper.com wrote:
This is a bug in your code. When you call die(), perl sets $? per the algorithm you describe (see Perl_my_failure_exit() in perl.c), and then it unwinds the stack. In your case you call system(), which sets $? to the value returned by wait(), which is 256 in this case. Since POSIX exit() only looks at the bottom 8 bits of the value your program returns 0. Tony |
|
The RT System itself - Status changed from 'new' to 'open' |
From @FGasperOn 27 Jan 2016 9:26 PM, Tony Cook via RT wrote:
( |
From @tonycozOn Wed, Jan 27, 2016 at 11:10:22PM -0500, Felipe Gasper wrote:
$? is initially set to 255 by die() using the algorithm you Later on, after the algorithm has set Tony |
From @FGasperOn 27 Jan 2016 11:30 PM, Tony Cook via RT wrote:
Wait, why would
Not according to perldoc -f die: exit ($? >> 8) is 1, so it should be doing exit(1), not exit(0). I actually pasted the wrong sample code earlier; I meant to post The bottom line is that, per the algorithm described in perldoc -f die, -FG |
From @tonycozOn Wed, Jan 27, 2016 at 11:37:49PM -0500, Felipe Gasper wrote:
Both die() or exit(), set $? to the exit value and then starts This isn't explicitly documented for die(), but they both manage the Tony |
From @FGasperOn 27 Jan 2016 11:49 PM, Tony Cook wrote:
By definition, then, that is an errant implementation of the -FG |
From zefram@fysh.orgFelipe Gasper wrote:
You're missing the point. It is documented (in perlvar(1)) that $? can It is poor design that $? has these two different uses. Especially so -zefram |
From @LeontOn Thu, Jan 28, 2016 at 11:48 PM, Zefram <zefram@fysh.org> wrote:
Yes, that :-/ I'm wondering what the effect would be of exiting with Leon |
From @FGasperOn 28 Jan 2016 5:49 PM, Zefram via RT wrote:
Hm. To where may I submit a pull request to add the following to perldoc -f die: Note that the determination of which variable to use for the exit value -FG |
From @FGasperOn 28 Jan 2016 6:09 PM, Leon Timmermans via RT wrote:
For that matter, why not read I can’t fathom what would depend on the behavior that Perl determines to -F |
From zefram@fysh.orgFelipe Gasper wrote:
That's not quite right. $?>>8 is relevant when initially determining As with an ordinary call to C<exit>, the exit code generated -zefram |
From zefram@fysh.orgFelipe Gasper wrote:
The more local that process is to the exception throwing, the better
Consider a program that has a strict exit code convention. It might -zefram |
From @FGasperOn 28 Jan 2016 9:00 PM, Zefram via RT wrote:
I think the disconnect, at least for myself, is the idea that an Evaluating Really, I still think this behavior violates the documentation. The Would there be a way to make it work that way? Alternatively to an additional blurb about how my propagate_exception_and_run_END_blocks(); exit( -F |
From @FGasperOn 28 Jan 2016 9:08 PM, Zefram via RT wrote:
It makes sense, of course, to preserve that functionality. My thinking is that reading 1) call stack reverse propagation ? -FG |
From zefram@fysh.orgFelipe Gasper wrote:
Yes, that's counter-intuitive. Possibly worth some explication.
That's exactly why we evaluate them at exception throwing. We want the
It does. You have to understand the exit() there as a Perl exit(),
No, it's accurate as it is. -zefram |
From @FGasperOn 29 Jan 2016 11:01 AM, Zefram via RT wrote:
Perhaps, but misleading, particularly when the lead-in phrase is: If an uncaught exception results in interpreter exit, the exit code is That does not sound (to me) like it’s talking about Perl’s exit(); Perhaps: If an exception is thrown outside of an eval {}, then prior to exception Particularly phrases like: “this means that the value of the exit code Again, IMO the more helpful workflow would be to examine Anyway. I think I’ve said my mind here. Thank you! -FG |
From @tonycozOn Fri Jan 29 08:28:10 2016, felipe@felipegasper.com wrote:
Maybe something like the attached. Tony |
From @tonycoz0001-perl-127386-clarify-that-exit-in-the-die-pseudo-code.patchFrom 652a3d4dbd81272ff4c5888dbe42829380f7e124 Mon Sep 17 00:00:00 2001
From: Tony Cook <tony@develop-help.com>
Date: Wed, 3 Feb 2016 14:25:04 +1100
Subject: [perl #127386] clarify that exit in the die pseudo-code is perl's
exit
---
pod/perlfunc.pod | 2 ++
1 file changed, 2 insertions(+)
diff --git a/pod/perlfunc.pod b/pod/perlfunc.pod
index 1dba05a..38f2080 100644
--- a/pod/perlfunc.pod
+++ b/pod/perlfunc.pod
@@ -1491,6 +1491,8 @@ If C<$@> is empty then the string C<"Died"> is used.
If an uncaught exception results in interpreter exit, the exit code is
determined from the values of C<$!> and C<$?> with this pseudocode:
+ # END blocks and destructors can modify $? and hence the program's
+ # exit code as with an other call to exit()
exit $! if $!; # errno
exit $? >> 8 if $? >> 8; # child exit status
exit 255; # last resort
--
2.1.4
|
From @FGasperOn 2 Feb 2016 10:25 PM, Tony Cook via RT wrote:
+ # END blocks and destructors can modify $? and hence the program's I think this would be helpful, yes. Thank you! I personally still think stating that die() behaves differently when $^S FWIW, maybe: If die() is called outside an eval {}, $? is set prior to propagation of -FG |
From @tonycozOn Wed Feb 03 02:34:26 2016, felipe@felipegasper.com wrote:
The attached replaces my original patch. I originally had both my original text and the new text (based on yours), but that seemed unreasonably repetitive. Tony |
From @tonycoz0001-perl-127386-clarify-that-exit-in-the-die-pseudo-code.patchFrom 8d70a8fac8cfb008b3e69b5307503b42772ebed0 Mon Sep 17 00:00:00 2001
From: Tony Cook <tony@develop-help.com>
Date: Tue, 9 Feb 2016 09:39:19 +1100
Subject: [perl #127386] clarify that exit in the die pseudo-code is perl's
exit
---
pod/perlfunc.pod | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/pod/perlfunc.pod b/pod/perlfunc.pod
index 87c61f4..afdaded 100644
--- a/pod/perlfunc.pod
+++ b/pod/perlfunc.pod
@@ -1495,6 +1495,10 @@ determined from the values of C<$!> and C<$?> with this pseudocode:
exit $? >> 8 if $? >> 8; # child exit status
exit 255; # last resort
+As with L</exit>, C<$?> is set prior to unwinding the call stack, any
+DESTROY or END handlers can then alter this value, and thus Perl's
+exit code.
+
The intent is to squeeze as much possible information about the likely cause
into the limited space of the system exit
code. However, as C<$!> is the value
--
2.1.4
|
From @FGasper+As with L</exit>, C<$?> is set prior to unwinding the call stack, any I like it! One niggle: it still doesn’t indicate the different behavior when die() As with L</exit>, L</die> called outside an L</eval> will set C<$?> (I split the sentences to avoid a comma splice. A semicolon could work -FG On 8 Feb 2016 4:45 PM, Tony Cook via RT wrote:
|
From @tonycozOn Mon Feb 08 14:51:51 2016, felipe@felipegasper.com wrote:
It's part of the continuing discussion about what happens when there's no eval, I don't think it's necessary to repeat it.
That END blocks and object destruction happen later follows on from the previous discussion, a semi-colon would work, I don't think a new sentence is appropriate. Tony |
From @FGasperOn 8 Feb 2016 5:08 PM, Tony Cook via RT wrote:
Perhaps, then, modify the paragraph that begins the section to: -If an uncaught exception results in interpreter exit, the exit +If L</die> is called when there is no L</eval> in the call stack, Anyhow, if $? will continue to be set before propagation rather than Thank you! -F |
From @tonycozOn Mon Feb 08 15:22:16 2016, felipe@felipegasper.com wrote:
I thought about that, and tried a few variations on the text, but didn't I've applied my most recent patch with a change from a comma to a semi-colon as 88aeef8. Tony |
|
@tonycoz - Status changed from 'open' to 'pending release' |
From @FGasperOn 22 Feb 2016 10:37 PM, Tony Cook via RT wrote:
Thank you! :) -FG |
From @khwilliamsonThank you for submitting this report. You have helped make Perl better. Perl 5.24.0 may be downloaded via https://metacpan.org/release/RJBS/perl-5.24.0 |
|
@khwilliamson - Status changed from 'pending release' to 'resolved' |
From nicolas@atoomic.orgNote that as an extension this program will die with an exit code of 0...
On Tue, 23 Feb 2016 00:03:08 -0800, felipe@felipegasper.com wrote:
|
Migrated from rt.perl.org#127386 (status was 'resolved')
Searchable as RT127386$
The text was updated successfully, but these errors were encountered: