A combination eval, DESTROY method and $@ - dangerous - bug #8257

p5pRT · 2005-12-25T20:15:53Z

Migrated from rt.perl.org#38034 (status was 'resolved')

Searchable as RT38034$

p5pRT · 2005-12-25T20:15:57Z

From root@localhost.localdomain

Created by root@localhost.localdomain

Brief:
If an some object is created in eval block under my operator and this object has a DESTROY method (for example, disconnect database method) then any threw exceptions in eval block are wiped and lost. I think that this is incorrect behaviour of perl. The perl should keep $@ if in eval there is some DESTROY methods...

To see example below

// Perlover (perlover@perlover.com)
Example:

eval

{
my $alex = Alex->new();
$alex->alex();
};

my $error = $@;

print "error = $error\n";

{
package Alex;

sub new
{
return bless {}, shift;
}

sub DESTROY
{
$@ = undef;
}

sub alex
{
die "Vasya cool";
}
}

Perl Info


Flags:
    category=core
    severity=medium

This perlbug was built using Perl v5.8.0 in the Red Hat build system.
It is being executed now by Perl v5.8.0 - Sat Dec 11 01:51:59 GMT 2004.

Site configuration information for perl v5.8.0:

Configured by root at Sat Dec 11 01:51:59 GMT 2004.

Summary of my perl5 (revision 5.0 version 8 subversion 0) configuration:
  Platform:
    osname=linux, osvers=2.4.21-20.0.1.el, archname=i386-linux-thread-multi
    uname='linux centos-build 2.4.21-20.0.1.el #1 fri dec 3 02:17:26 gmt 2004 i686 athlon i386 gnulinux '
    config_args='-des -Doptimize=-O2 -g -pipe -march=i386 -mcpu=i686 -Dmyhostname=localhost -Dperladmin=root@localhost -Dcc=gcc -Dcf_by=Red Hat, Inc. -Dinstallprefix=/usr -Dprefix=/usr -Darchname=i386-linux -Dvendorprefix=/usr -Dsiteprefix=/usr -Dotherlibdirs=/usr/lib/perl5/5.8.0 -Duseshrplib -Dusethreads -Duseithreads -Duselargefiles -Dd_dosuid -Dd_semctl_semun -Di_db -Ui_ndbm -Di_gdbm -Di_shadow -Di_syslog -Dman3ext=3pm -Duseperlio -Dinstallusrbinperl -Ubincompat5005 -Uversiononly -Dpager=/usr/bin/less -isr'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=define use5005threads=undef useithreads=define usemultiplicity=define
    useperlio=define d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
    usemymalloc=n, bincompat5005=undef
  Compiler:
    cc='gcc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/include/gdbm',
    optimize='-O2 -g -pipe -march=i386 -mcpu=i686',
    cppflags='-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS -DDEBUGGING -fno-strict-aliasing -I/usr/local/include -I/usr/include/gdbm'
    ccversion='', gccversion='3.2.3 20030502 (Red Hat Linux 3.2.3-42)', gccosandvers=''
    intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234
    d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=12
    ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
    alignbytes=4, prototype=define
  Linker and Libraries:
    ld='gcc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lgdbm -ldb -ldl -lm -lpthread -lc -lcrypt -lutil
    perllibs=-lnsl -ldl -lm -lpthread -lc -lcrypt -lutil
    libc=/lib/libc-2.3.2.so, so=so, useshrplib=true, libperl=libperl.so
    gnulibc_version='2.3.2'
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic -Wl,-rpath,/usr/lib/perl5/5.8.0/i386-linux-thread-multi/CORE'
    cccdlflags='-fPIC', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    MAINT18379


@INC for perl v5.8.0:
    /usr/lib/perl5/5.8.0/i386-linux-thread-multi
    /usr/lib/perl5/5.8.0
    /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
    /usr/lib/perl5/site_perl/5.8.0
    /usr/lib/perl5/site_perl
    /usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
    /usr/lib/perl5/vendor_perl/5.8.0
    /usr/lib/perl5/vendor_perl
    /usr/lib/perl5/5.8.0/i386-linux-thread-multi
    /usr/lib/perl5/5.8.0
    .


Environment for perl v5.8.0:
    HOME=/root
    LANG=en_US.iso885915
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/root/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash

p5pRT · 2006-01-02T15:43:32Z

From @smpeters

[root@localhost.localdomain - Sun Dec 25 12:15:57 2005]:

This is a bug report for perl from root@localhost.localdomain,
generated with the help of perlbug 1.34 running under perl v5.8.0.

-----------------------------------------------------------------
[Please enter your report here]

Brief:
If an some object is created in eval block under my operator and this
object has a DESTROY method (for example, disconnect database
method) then any threw exceptions in eval block are wiped and lost.
I think that this is incorrect behaviour of perl. The perl should
keep $@ if in eval there is some DESTROY methods...

To see example below

// Perlover (perlover@perlover.com)
Example:

eval

{
my $alex = Alex->new();
$alex->alex();
};

my $error = $@;

print "error = $error\n";

{
package Alex;

sub new
{
return bless {}, shift;
}

sub DESTROY
{
$@ = undef;
}

sub alex
{
die "Vasya cool";
}
}

But what if the scenario you show above is exactly what I want? It may
not be the wisest choice in writing a Perl module, but I do not see
where it is a bug. Anyone else have any comments?

p5pRT · 2006-01-02T15:43:33Z

The RT System itself - Status changed from 'new' to 'open'

p5pRT · 2006-01-02T15:54:34Z

From @ysth

On Mon, Jan 02, 2006 at 07:43:32AM -0800, Steve Peters via RT wrote:

[root@localhost.localdomain - Sun Dec 25 12:15:57 2005]:

This is a bug report for perl from root@localhost.localdomain,
generated with the help of perlbug 1.34 running under perl v5.8.0.

-----------------------------------------------------------------
[Please enter your report here]

Brief:
If an some object is created in eval block under my operator and this
object has a DESTROY method (for example, disconnect database
method) then any threw exceptions in eval block are wiped and lost.
I think that this is incorrect behaviour of perl. The perl should
keep $@ if in eval there is some DESTROY methods...

To see example below

// Perlover (perlover@perlover.com)
Example:

eval

{
my $alex = Alex->new();
$alex->alex();
};

my $error = $@;

print "error = $error\n";

{
package Alex;

sub new
{
return bless {}, shift;
}

sub DESTROY
{
$@ = undef;
}

sub alex
{
die "Vasya cool";
}
}

But what if the scenario you show above is exactly what I want? It may
not be the wisest choice in writing a Perl module, but I do not see
where it is a bug. Anyone else have any comments?

You can prevent DESTROY methods from affecting $@ by starting them with
local $@;

p5pRT · 2006-01-02T18:39:40Z

@smpeters - Status changed from 'open' to 'resolved'

p5pRT · 2006-01-03T18:53:36Z

From mjtg@cam.ac.uk

Yitzchak Scott-Thoennes <sthoenna@efn.org> wrote

You can prevent DESTROY methods from affecting $@ by starting them with
local $@;

This fact is notoriously underdocumented; I suggest the attached.

Mike Guy

Inline Patch

--- ./pod/perlobj.pod.orig	2003-07-10 07:12:41.000000000 +0100
+++ ./pod/perlobj.pod	2006-01-03 18:48:55.479193000 +0000
@@ -433,6 +433,11 @@
 the thingy the reference points to, namely C<${$_[0]}>, C<@{$_[0]}>, 
 C<%{$_[0]}> etc.) is not similarly constrained.
 
+Since DESTROY methods can be called at unpredictable times, it is
+important that you localise any global variables that the method may
+update.  In particular, localise C<$@> if you use C<exec {} and
+localise C<$?> if you use C<system> or backticks.
+
 If you arrange to re-bless the reference before the destructor returns,
 perl will again call the DESTROY method for the re-blessed object after
 the current one returns.  This can be used for clean delegation of

End of patch

p5pRT · 2006-01-03T19:04:28Z

From mjtg@cam.ac.uk

Ooops - typo. Try again.

Mike Guy

Inline Patch

--- ./pod/perlobj.pod.orig	2003-07-10 07:12:41.000000000 +0100
+++ ./pod/perlobj.pod	2006-01-03 18:48:55.479193000 +0000
@@ -433,6 +433,11 @@
 the thingy the reference points to, namely C<${$_[0]}>, C<@{$_[0]}>, 
 C<%{$_[0]}> etc.) is not similarly constrained.
 
+Since DESTROY methods can be called at unpredictable times, it is
+important that you localise any global variables that the method may
+update.  In particular, localise C<$@> if you use C<exec {}> and
+localise C<$?> if you use C<system> or backticks.
+
 If you arrange to re-bless the reference before the destructor returns,
 perl will again call the DESTROY method for the re-blessed object after
 the current one returns.  This can be used for clean delegation of

End of patch

p5pRT · 2006-01-03T19:19:06Z

From mjtg@cam.ac.uk

Joshua ben Jore <twists@gmail.com> wrote

Didn't you mean eval {}?

Bah! Haven't recovered from New Year's Eve yet. Try 3:

Mike Guy

Inline Patch

--- ./pod/perlobj.pod.orig	2003-07-10 07:12:41.000000000 +0100
+++ ./pod/perlobj.pod	2006-01-03 18:48:55.479193000 +0000
@@ -433,6 +433,11 @@
 the thingy the reference points to, namely C<${$_[0]}>, C<@{$_[0]}>, 
 C<%{$_[0]}> etc.) is not similarly constrained.
 
+Since DESTROY methods can be called at unpredictable times, it is
+important that you localise any global variables that the method may
+update.  In particular, localise C<$@> if you use C<eval {}> and
+localise C<$?> if you use C<system> or backticks.
+
 If you arrange to re-bless the reference before the destructor returns,
 perl will again call the DESTROY method for the re-blessed object after
 the current one returns.  This can be used for clean delegation of

End of patch

p5pRT · 2006-01-03T20:08:45Z

From @smpeters

On Tue, Jan 03, 2006 at 07:18:41PM +0000, Mike Guy wrote:

Joshua ben Jore <twists@gmail.com> wrote

Didn't you mean eval {}?

Bah! Haven't recovered from New Year's Eve yet. Try 3:

Try 3 added as change #26625.

Thanks!

Steve Peters
steve@fisharerojo.org

p5pRT · 2006-01-05T18:28:25Z

From nick@ing-simmons.net

Mike Guy <mjtg@cam.ac.uk> writes:

Ooops - typo. Try again.

Mike Guy

--- ./pod/perlobj.pod.orig 2003-07-10 07:12:41.000000000 +0100
+++ ./pod/perlobj.pod 2006-01-03 18:48:55.479193000 +0000
@@ -433,6 +433,11 @@
the thingy the reference points to, namely C<${$_[0]}>, C<@{$_[0]}>,
C<%{$_[0]}> etc.) is not similarly constrained.

+Since DESTROY methods can be called at unpredictable times, it is
+important that you localise any global variables that the method may
+update. In particular, localise C<$@> if you use C<exec {}> and

Did you mean C<eval> there?

+localise C<$?> if you use C<system> or backticks.
+
If you arrange to re-bless the reference before the destructor returns,
perl will again call the DESTROY method for the re-blessed object after
the current one returns. This can be used for clean delegation of

End of patch

p5pRT closed this as completed Jan 2, 2006

p5pRT added Severity Medium distro-Linux type-core labels Oct 18, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

A combination eval, DESTROY method and $@ - dangerous - bug #8257

A combination eval, DESTROY method and $@ - dangerous - bug #8257

p5pRT commented Dec 25, 2005

p5pRT commented Dec 25, 2005

p5pRT commented Jan 2, 2006

p5pRT commented Jan 2, 2006

p5pRT commented Jan 2, 2006

p5pRT commented Jan 2, 2006

p5pRT commented Jan 3, 2006

p5pRT commented Jan 3, 2006

p5pRT commented Jan 3, 2006

p5pRT commented Jan 3, 2006

p5pRT commented Jan 5, 2006

A combination eval, DESTROY method and $@ - dangerous - bug #8257

A combination eval, DESTROY method and $@ - dangerous - bug #8257

Comments

p5pRT commented Dec 25, 2005

p5pRT commented Dec 25, 2005

From root@localhost.localdomain

Created by root@localhost.localdomain

p5pRT commented Jan 2, 2006

From @smpeters

p5pRT commented Jan 2, 2006

p5pRT commented Jan 2, 2006

From @ysth

p5pRT commented Jan 2, 2006

p5pRT commented Jan 3, 2006

From mjtg@cam.ac.uk

p5pRT commented Jan 3, 2006

From mjtg@cam.ac.uk

p5pRT commented Jan 3, 2006

From mjtg@cam.ac.uk

p5pRT commented Jan 3, 2006

From @smpeters

p5pRT commented Jan 5, 2006

From nick@ing-simmons.net