[BUG] can't exit 0 from CHECK{}

[p5pRT]

Migrated from rt.perl.org#2754 (status was 'open')

Searchable as RT2754$

[p5pRT]

From tchrist@chthon.perl.com

From a CHECK{}, you cannot exit(0). You may exit !0, but not 0.
If you put this in /tmp/a and run it​:

  #BEGIN { warn "testing exit from BEGIN"; exit }
  #BEGIN { warn "testing exit N from BEGIN"; exit 1 }

  #INIT { warn "testing exit from INIT"; exit }
  #INIT { warn "testing exit N from INIT"; exit 2 }

  CHECK { warn "testing exit from CHECK"; exit }
  #CHECK { warn "testing exit N from CHECK"; exit 3 }

  #END { warn "testing exit from END"; exit }
  #END { warn "testing exit N from END"; exit 4 }

  print "i am now the main program\n";
  warn "testing exit 5 from main";
  exit 5;

  die "XXX";

You will get​:

  % perl /tmp/a
  testing exit from CHECK at /tmp/a line 7.
  i am now the main program
  testing exit 5 from main at /tmp/a line 14.
  Exit 5

If you switch the comment on the two CHECKs, you get

  % perl /tmp/a
  testing exit N from CHECK at /tmp/a line 8.
  Exit 3

--tom

[p5pRT]

From @floatingatoll

[tchrist@​chthon.perl.com - Tue Mar 28 03​:39​:19 2000]​:

From a CHECK{}, you cannot exit(0). You may exit !0, but not 0.
If you put this in /tmp/a and run it​:

\#BEGIN \{ warn "testing exit from BEGIN"; exit \}
\#BEGIN \{ warn "testing exit N from BEGIN"; exit 1 \}

\#INIT \{ warn "testing exit from INIT"; exit \}
\#INIT \{ warn "testing exit N from INIT"; exit 2 \}

CHECK \{ warn "testing exit from CHECK"; exit \}
\#CHECK \{ warn "testing exit N from CHECK"; exit 3 \}

\#END \{ warn "testing exit from END"; exit \}
\#END \{ warn "testing exit N from END"; exit 4 \}

print "i am now the main program\\n";
warn "testing exit 5 from main";
exit 5;

die "XXX";

You will get​:

% perl /tmp/a
testing exit from CHECK at /tmp/a line 7\.
i am now the main program
testing exit 5 from main at /tmp/a line 14\.
Exit 5

If you switch the comment on the two CHECKs, you get

% perl /tmp/a
testing exit N from CHECK at /tmp/a line 8\.
Exit 3

Confirmed this bug is present as of @​17821.

[p5pRT]

From @chorny

Still present in 5.12.0 RC0.

On Tue Mar 28 03​:39​:19 2000, tchrist@​chthon.perl.com wrote​:

From a CHECK{}, you cannot exit(0). You may exit !0, but not 0.
If you put this in /tmp/a and run it​:

\#BEGIN \{ warn "testing exit from BEGIN"; exit \}
\#BEGIN \{ warn "testing exit N from BEGIN"; exit 1 \}

\#INIT \{ warn "testing exit from INIT"; exit \}
\#INIT \{ warn "testing exit N from INIT"; exit 2 \}

CHECK \{ warn "testing exit from CHECK"; exit \}
\#CHECK \{ warn "testing exit N from CHECK"; exit 3 \}

\#END \{ warn "testing exit from END"; exit \}
\#END \{ warn "testing exit N from END"; exit 4 \}

print "i am now the main program\\n";
warn "testing exit 5 from main";
exit 5;

die "XXX";

You will get​:

% perl /tmp/a
testing exit from CHECK at /tmp/a line 7\.
i am now the main program
testing exit 5 from main at /tmp/a line 14\.
Exit 5

If you switch the comment on the two CHECKs, you get

% perl /tmp/a
testing exit N from CHECK at /tmp/a line 8\.
Exit 3

--
Alexandr Ciornii, http​://chorny.net

[p5pRT]

From @Abigail

On Mon, Apr 12, 2010 at 03​:50​:52AM -0700, Alexandr Ciornii via RT wrote​:

On Tue Mar 28 03​:39​:19 2000, tchrist@​chthon.perl.com wrote​:

From a CHECK{}, you cannot exit(0). You may exit !0, but not 0.
If you put this in /tmp/a and run it​:

\#BEGIN \{ warn "testing exit from BEGIN"; exit \}
\#BEGIN \{ warn "testing exit N from BEGIN"; exit 1 \}

\#INIT \{ warn "testing exit from INIT"; exit \}
\#INIT \{ warn "testing exit N from INIT"; exit 2 \}

CHECK \{ warn "testing exit from CHECK"; exit \}
\#CHECK \{ warn "testing exit N from CHECK"; exit 3 \}

\#END \{ warn "testing exit from END"; exit \}
\#END \{ warn "testing exit N from END"; exit 4 \}

print "i am now the main program\\n";
warn "testing exit 5 from main";
exit 5;

die "XXX";

You will get​:

% perl /tmp/a
testing exit from CHECK at /tmp/a line 7\.
i am now the main program
testing exit 5 from main at /tmp/a line 14\.
Exit 5

If you switch the comment on the two CHECKs, you get

% perl /tmp/a
testing exit N from CHECK at /tmp/a line 8\.
Exit 3

Still present in 5.12.0 RC0.

And in 5.12.0-RC5 as well. However, it's not a regression for a recent
Perl. It behaves the same in 5.10.1, 5.8.[89] and 5.6.2.

It is a regression from 5.005_04 though, which will print the expected​:

  testing exit from CHECK at bb line 14.

Abigail

[p5pRT]

From @gannett-ggreer

On Tue Mar 28 03​:39​:19 2000, tchrist@​chthon.perl.com wrote​:

From a CHECK{}, you cannot exit(0). You may exit !0, but not 0.
If you put this in /tmp/a and run it​:

\#BEGIN \{ warn "testing exit from BEGIN"; exit \}
\#BEGIN \{ warn "testing exit N from BEGIN"; exit 1 \}

\#INIT \{ warn "testing exit from INIT"; exit \}
\#INIT \{ warn "testing exit N from INIT"; exit 2 \}

CHECK \{ warn "testing exit from CHECK"; exit \}
\#CHECK \{ warn "testing exit N from CHECK"; exit 3 \}

\#END \{ warn "testing exit from END"; exit \}
\#END \{ warn "testing exit N from END"; exit 4 \}

print "i am now the main program\\n";
warn "testing exit 5 from main";
exit 5;

die "XXX";

You will get​:

% perl /tmp/a
testing exit from CHECK at /tmp/a line 7\.
i am now the main program
testing exit 5 from main at /tmp/a line 14\.
Exit 5

If you switch the comment on the two CHECKs, you get

% perl /tmp/a
testing exit N from CHECK at /tmp/a line 8\.
Exit 3

The problem (as of today's Perl) is that perl_parse() returns the exit
status as if it were going back to the OS. In main(), perl does​:
"exitstatus = perl_parse(...); if (!exitstatus) perl_run(...);' Which
means main() can't tell the difference between normal execution (0 from
JMPENV) and my_exit (2 from JMPENV) because the my_exit case sets the
return value to the exit code (0).

perl_parse() is flagged as public API so my patch below is unacceptable
although it does fix the immediate problem. I include it more as
illustration than for inclusion (which is why it is a 'diff', not a
'commit'). It does, however, pass all tests which makes me think there
should be tests that the public API is stable.

I appeal to greater powers for a "public API"-acceptable fix. :)

--
George Greer

[p5pRT]

From @gannett-ggreer

nak.patch

diff --git a/perl.c b/perl.c
index 0edad78..8815ed1 100644
--- a/perl.c
+++ b/perl.c
@@ -1606,11 +1606,8 @@ perl_parse(pTHXx_ XSINIT_t xsinit, int argc, char **argv, char **env)
 	    call_list(oldscope, PL_unitcheckav);
 	if (PL_checkav)
 	    call_list(oldscope, PL_checkav);
-	ret = 0;
 	break;
     case 1:
-	STATUS_ALL_FAILURE;
-	/* FALL THROUGH */
     case 2:
 	/* my_exit() was called */
 	while (PL_scopestack_ix > oldscope)
@@ -1621,11 +1618,9 @@ perl_parse(pTHXx_ XSINIT_t xsinit, int argc, char **argv, char **env)
 	    call_list(oldscope, PL_unitcheckav);
 	if (PL_checkav)
 	    call_list(oldscope, PL_checkav);
-	ret = STATUS_EXIT;
 	break;
     case 3:
 	PerlIO_printf(Perl_error_log, "panic: top_env\n");
-	ret = 1;
 	break;
     }
     JMPENV_POP;

[p5pRT]

From tchrist@perl.com

  +---------------------------------------------------------------------+
  | This is automatic mail from Tom Christiansen's answering service. |
  | UPDATED​: Saturday, 2010 July 10 18​:01​:10 MDT 2010 |
  +---------------------------------------------------------------------+

  I'm away from the office, up in the Colorado wilderness,
  minimally until Wednesday, July 14th. I do *not* expect
  to have email or phone access while I'm away.

  I'll do my best to get back to you as soon as I return.

  --tom

[p5pRT]

From @Hugmeir

On Sun Jul 11 00​:23​:23 2010, greerga wrote​:

On Tue Mar 28 03​:39​:19 2000, tchrist@​chthon.perl.com wrote​:

From a CHECK{}, you cannot exit(0). You may exit !0, but not 0.
If you put this in /tmp/a and run it​:

\#BEGIN \{ warn "testing exit from BEGIN"; exit \}
\#BEGIN \{ warn "testing exit N from BEGIN"; exit 1 \}

\#INIT \{ warn "testing exit from INIT"; exit \}
\#INIT \{ warn "testing exit N from INIT"; exit 2 \}

CHECK \{ warn "testing exit from CHECK"; exit \}
\#CHECK \{ warn "testing exit N from CHECK"; exit 3 \}

\#END \{ warn "testing exit from END"; exit \}
\#END \{ warn "testing exit N from END"; exit 4 \}

print "i am now the main program\\n";
warn "testing exit 5 from main";
exit 5;

die "XXX";

You will get​:

% perl /tmp/a
testing exit from CHECK at /tmp/a line 7\.
i am now the main program
testing exit 5 from main at /tmp/a line 14\.
Exit 5

If you switch the comment on the two CHECKs, you get

% perl /tmp/a
testing exit N from CHECK at /tmp/a line 8\.
Exit 3

The problem (as of today's Perl) is that perl_parse() returns the exit
status as if it were going back to the OS. In main(), perl does​:
"exitstatus = perl_parse(...); if (!exitstatus) perl_run(...);' Which
means main() can't tell the difference between normal execution (0 from
JMPENV) and my_exit (2 from JMPENV) because the my_exit case sets the
return value to the exit code (0).

perl_parse() is flagged as public API so my patch below is unacceptable
although it does fix the immediate problem. I include it more as
illustration than for inclusion (which is why it is a 'diff', not a
'commit'). It does, however, pass all tests which makes me think there
should be tests that the public API is stable.

I appeal to greater powers for a "public API"-acceptable fix. :)

I reappeal to greater powers for a "public API"-acceptable fix. Would be
nice to get this bug closed once and for all!

[p5pRT]

From @wolfsage

On Fri May 04 12​:15​:22 2012, Hugmeir wrote​:

I appeal to greater powers for a "public API"-acceptable fix. :)

I reappeal to greater powers for a "public API"-acceptable fix. Would be
nice to get this bug closed once and for all!

Hmm, does this actually break the contract of the public API?

The docs that I've found don't specify any specific return values, they
just show through example that​:

(From perlembed.pod)
  exitstatus = perl_parse(my_perl, NULL, 2, embedding, NULL);
  PL_exit_flags |= PERL_EXIT_DESTRUCT_END;
  if(!exitstatus) {
  exitstatus = perl_run(my_perl);

So as long as perl_parse returns a false value when it succeeds, we
should be good?

-- Matthew Horsfall (alh)

[p5pRT]

From @cpansprout

On Sun Nov 25 05​:31​:01 2012, alh wrote​:

On Fri May 04 12​:15​:22 2012, Hugmeir wrote​:

I appeal to greater powers for a "public API"-acceptable fix. :)

I reappeal to greater powers for a "public API"-acceptable fix. Would be
nice to get this bug closed once and for all!

Hmm, does this actually break the contract of the public API?

The docs that I've found don't specify any specific return values, they
just show through example that​:

(From perlembed.pod)
exitstatus = perl_parse(my_perl, NULL, 2, embedding, NULL);
PL_exit_flags |= PERL_EXIT_DESTRUCT_END;
if(!exitstatus) {
exitstatus = perl_run(my_perl);

So as long as perl_parse returns a false value when it succeeds, we
should be good?

I think we need to rethink (carefully!) how perl handles this
internally. That BEGIN{exit 0} exits the program and CHECK{exit 0} does
not seems like the implementation details leaking through.

--

Father Chrysostomos

[p5pRT]

From zefram@fysh.org

Oh boy, this was a fun one. The basic problem is that the return value
from perl_parse() is overloaded. Is it a truth value or an exit code?
If an exit code, is it a Unix-style exit code or a native exit code?
The perlembed tutorial disagreed with perlmain.c and had a bunch of flaws
that mark it as an unreliable source, and the function wasn't actually
documented other than by reference to perlembed.

We can preserve most of the overloaded use of perl_parse()'s return value
by the very simple expedient of returning 0x100 for a zero exit code,
leaving an actual zero return value to indicate that we're not exiting.
On Unix this is a total fix. On other OSes an equivalent trick might be
possible, but might not, depending on local conventions for exit codes.
(It's clear enough that perl_parse()'s return value has the significance
of a native exit code, despite the Unix-centric assumptions that crept
in.) It should in any case return non-zero for a zero native exit code
regardless of platform​: that means that an exit with zero native exit
code will at least always be interpreted as exiting, so the remaining
misbehaviour will only consist of exiting with the wrong exit code.

For users to get the correct exit code they need to interpret
perl_parse()'s return value the way perlmain.c does​: as a truth value,
with the actual exit code coming from perl_destruct(). perlembed needs
to show this mode of usage.

I have done all this (and some more) in commit
0301e89. That resolves this ticket.

-zefram

[p5pRT]

@cpansprout - Status changed from 'open' to 'pending release'

[p5pRT]

From zefram@fysh.org

In order to give Module​::Install distros more time to roll out a fix
for [perl #132577], this bug [perl #2754] has been reintroduced in
commit 857320c. This ticket should
be reopened. The plan is to revert the bug reintroduction during the
5.29 development cycle. This issue should block 5.30.0.

-zefram

[p5pRT]

From @xsawyerx

Following this, we should formulate a plan for dealing with these
distributions and having them release new versions. We have time but our
goal is to still have this bug fix in the next version and this could
only be done if we are able to have enough distributions released with
the fix.

Zefram, is it possible to provide a succinct way to explain this change
to module authors when we submit patches or request the changes made?

On 12/27/2017 11​:26 PM, Zefram wrote​:

In order to give Module​::Install distros more time to roll out a fix
for [perl #132577], this bug [perl #2754] has been reintroduced in
commit 857320c. This ticket should
be reopened. The plan is to revert the bug reintroduction during the
5.29 development cycle. This issue should block 5.30.0.

-zefram