FAQ
This ticket should say:

Severity: High
Perl Version: 5.8.0, 5.8.4, 5.8.8, 5.10.0-RC2 & probably all in between.
Operating System: Linux, Solaris, & probably all unixish and more.

This bug will spookily generate false positive eval results in any
program that uses eval and handles async signals (returns from handlers).

To fix this bug and restore the pre-5.8 behaviour, make
Perl_sighandler() enter scope and localise ERRSV before call_sv(), leave
scope and copy ERRSV thereafter. Then, after the special processing
that motivated the use of G_EVAL, it should test and (if true) die with
the copy, rather than ERRSV.

In other words, Perl_sighandler() needs to do the C equivalent of:

my $err;
{ local $@;
eval ...;
$err = $@; }
...
die($err) if $err;

instead of the current:

eval ...;
die($@) if $@;


By the way, unfriendly RT rejects my edits:

* Could not add new custom field value: Permission Denied
* Could not add new custom field value: Permission Denied
* Could not add new custom field value: Permission Denied
* Could not add new custom field value: Permission Denied
* Could not add new custom field value: Permission Denied
* Could not add new custom field value: Permission Denied
* Permission Denied

Search Discussions

  • Joshua ben Jore at Dec 11, 2007 at 9:37 am

    On Dec 10, 2007 2:50 PM, John Tobey via RT wrote:
    This ticket should say:

    Severity: High
    Perl Version: 5.8.0, 5.8.4, 5.8.8, 5.10.0-RC2 & probably all in between.
    Operating System: Linux, Solaris, & probably all unixish and more.

    This bug will spookily generate false positive eval results in any
    program that uses eval and handles async signals (returns from handlers).
    Two things. I see nothing wrong with my results of running your
    program and you aren't supposed to use $@ as a boolean. If you do, you
    risk getting false positives and negatives. $@ cannot be used a
    boolean in Perl 5 and it's a bug in your code if you use it that way.

    $@=
    $before=hello
    $during=
    $after=

    $@ can be false after error because an eval{} happened during a ->DESTROY.
    $@ can be true after *NO* error because an a die happened during a
    ->DESTROY. The eval will still succeed though.
    $@ could be tied and act arbitrarily.
    The value $@ in could be an overloaded object. If coded poorly,
    examining the value clobbers $@. In fact, at work $@ usually is a
    stringification overloaded object. An earlier iteration computed "$@"
    improperly and would clobber $@ during the compute.

    In general you must always examine the result of eval{} to see if the
    block succeeded. For the rare case where the eval block succeeds, one
    ->DESTROY fails and another ->DESTROY suceeds, the failing code can
    only be detected by having a $SIG{__DIE__} handler. I hope Perl 6
    fixes this mess.

    Josh
  • John Tobey via RT at Dec 11, 2007 at 5:00 pm

    On Tue Dec 11 01:38:04 2007, jjore wrote:

    Two things. I see nothing wrong with my results of running your
    program and you aren't supposed to use $@ as a boolean. If you do, you
    risk getting false positives and negatives. $@ cannot be used a
    boolean in Perl 5 and it's a bug in your code if you use it that way.
    Please refer to the example in the original bug report, not the
    pseudocode illustrating Perl_sighandler:
    http://rt.perl.org/rt3/Ticket/Display.html?id=47928

    You have to meditate a little to appreciate the bug. If your program
    uses asynchronous signals, then $@ may be cleared at any time. In
    particular, it is cleared if a signal is received between an eval
    statement and subsequent examination of $@.

    Example:

    $SIG{ALRM} = sub { $got_ALRM = 1; };
    alarm(1);
    unless (eval sub { anything(); 1 }) {

    ### ALRM SIGNAL HERE CLEARS $@

    print("error:$@");
    }

    The fix is simple but requires changes to Perl_sighandler() in mg.c.

    By the way, though it's irrelevant to the bug, several places in the
    official documentation use $@ as a boolean. Several places in the
    interpreter do the same as SvTRUE(ERRSV).

    Regards,
    John
  • Joshua ben Jore at Dec 12, 2007 at 3:56 am

    On Dec 11, 2007 9:00 AM, John Tobey via RT wrote:
    On Tue Dec 11 01:38:04 2007, jjore wrote:
    By the way, though it's irrelevant to the bug, several places in the
    official documentation use $@ as a boolean. Several places in the
    interpreter do the same as SvTRUE(ERRSV).
    Until proven otherwise, all those places are bugs. It's true that in
    general $@ works fine as a boolean but perl isn't so straightforward
    that you can /always/ use it.

    Josh

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupperl5-porters @
categoriesperl
postedDec 10, '07 at 10:50p
activeDec 12, '07 at 3:56a
posts4
users3
websiteperl.org

People

Translate

site design / logo © 2021 Grokbase