$@ empty after die in eval{}

p5pRT commented 20 years ago

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

Searchable as RT23723$

p5pRT commented 20 years ago

From Michael.Jacob3@de.ibm.com

Created by micaja@de.ibm.com

Our (closed source) Perl program has now reached 10.000 lines\, and I could not reproduce the problem with a small demo. So this report will probably not help anybody reproduce the problem\, sorry for that.

Our problem is that the $@ variable stops working. We have a large eval{} in a testcase. The 14th test creates a new object. If I place a die() before that test it works as it should\, $@ will have the value I gave to die(). If I place a die() after test 14\, $@ will be '' (empty string) after the eval.

I cannot see anything special at the 14th test\, the most "unusual" thing it does is to SELECT from a database (DBD::CSV).

The following modules are used in our project:

use Data::Compare; use Data::Dumper; use DBI; (with DBD::CSV) use Digest::MD5; use IO::File; use Log::Log4perl; use POSIX; use Socket; use Storable; use strict; use Tie::Hash; use utf8; use warnings; use WeakRef;

The modules from CPAN were installed within the last 3 weeks.

I checked $SIG{__DIE__}\, it's content does not affect the behavior. I can workaround the problem with:

our $___e = undef; our $oldSIGDIE = $SIG{__DIE__} || sub {}; $SIG{__DIE__} = sub { $___e = $@; goto &$oldSIGDIE; }

but I really don't like it.

I tried to follow the program executionwith the Perl debugger\, but I could not see anything that could have affected the problem.

I believe it is a Perl problem (and not a problem with one of the modules) because I can do this:

our $___e = undef; $SIG{__DIE__} = sub { $___e = $@; } eval { ... complex program here die 1; }; print "BUG" if $___e ne $@; # will fire! print "BUG" if not $@; # will fire!

We also tested the code under a Perl 5.8.0 on a Debian(unstable). Same problem there\, so it's not Win32 specific.

Please help me finding the cause of the problem. I don't expect to get a "ready-to-use" patch\, I will be happy enaugh if I can find the line of code\, that "disables" $@. I have a (dirty) workaround\, but I really would like to know if I know all side-effects of the problem...

Thank you.

Perl Info

``` Flags: category=core severity=medium Site configuration information for perl v5.8.0: Configured by ActiveState at Tue Feb 4 18:07:44 2003. Summary of my perl5 (revision 5 version 8 subversion 0) configuration: Platform: osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread uname='' config_args='undef' hint=recommended, useposix=true, d_sigaction=undef usethreads=undef 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='cl', ccflags ='-nologo -Gf -W3 -MD -Zi -DNDEBUG -O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX', optimize='-MD -Zi -DNDEBUG -O1', cppflags='-DWIN32' ccversion='', gccversion='', gccosandvers='' intsize=4, longsize=4, ptrsize=4, doublesize=8, byteorder=1234 d_longlong=undef, longlongsize=8, d_longdbl=define, longdblsize=10 ivtype='long', ivsize=4, nvtype='double', nvsize=8, Off_t='__int64', lseeksize=8 alignbytes=8, prototype=define Linker and Libraries: ld='link', ldflags ='-nologo -nodefaultlib -debug -opt:ref,icf -libpath:"C:\Perl580\lib\CORE" -machine:x86' libpth="C:\Perl580\lib\CORE" libs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib perllibs= oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib netapi32.lib uuid.lib wsock32.lib mpr.lib winmm.lib version.lib odbc32.lib odbccp32.lib msvcrt.lib libc=msvcrt.lib, so=dll, useshrplib=yes, libperl=perl58.lib gnulibc_version='undef' Dynamic Linking: dlsrc=dl_win32.xs, dlext=dll, d_dlsymun=undef, ccdlflags=' ' cccdlflags=' ', lddlflags='-dll -nologo -nodefaultlib -debug -opt:ref,icf -libpath:"C:\Perl580\lib\CORE" -machine:x86' Locally applied patches: ACTIVEPERL_LOCAL_PATCHES_ENTRY @INC for perl v5.8.0: c:/Perl580/lib c:/Perl580/site/lib . Environment for perl v5.8.0: HOME (unset) LANG (unset) LANGUAGE (unset) LD_LIBRARY_PATH (unset) LOGDIR (unset) PATH=C:\WINNT\system32;C:\WINNT;C:\WINNT\system32\WBEM;c: \perl580\bin;c:\cygwin\bin;C:\Program Files\UltraEdit;C:\WINNT\system32;C: \WINNT;C:\WINNT\system32\WBEM;c:\perl580\bin;c:\cygwin\bin PERL_BADLANG (unset) PERL_DL_NOLAZY=1 SHELL (unset) /mfg/ Michael Jacob ############################################################ Phone: +49-69-6645-3623 (internal: *134-3623) Mobile: +49-172-6350425 ############################################################ Other company, product or service names may be trademarks or service marks of others. ```

p5pRT commented 20 years ago

From perl_dummy@bloodgate.com

-----BEGIN PGP SIGNED MESSAGE-----

Moin Michael\,

Our (closed source) Perl program has now reached 10.000 lines\, and I could not reproduce the problem with a small demo. So this report will probably not help anybody reproduce the problem\, sorry for that. [snip a bisserl]

Michael\, I am sorry that I cannot help you\, both because I do not have access to a small testcase nor your source code\, and because my knowledge of the internals of Perl is not sufficient enough.

It might be a good idea to nudge your PHB into releasing the source of your application. Having gone through that process I can ensure you that this usually improves the quality of the source\, and also avoids awkward situations like this :-) If you want some support in this matter\, please contact me off-list.

Thank you for your bugreport!

Best wishes\,

Tels

- -- Signed on Thu Sep 4 23:39:20 2003 with key 0x93B84C15. PGP key on http://bloodgate.com/tels.asc or per email.

"Yeah\, baby\, yeah!"

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) Comment: When cryptography is outlawed\, bayl bhgynjf jvyy unir cevinpl.

iQEVAwUBP1exzXcLPEOTuEwVAQGoWQf/QYXtV2zAuTMVgJzbk3+YSHDUNnErYLm+ hQHC01f6YJ2OAjv/bWoYuOUzTZQaSK7rVe5uTr1bzJAZKCdFCRzkCPZELLHaBZyX po7mFTjlEDr6/Z+DEfSYf+O7QBV4fzm65tipQzgDhSmEDTpIrkfZ/gyTWkn5njPV y81oK91FFBz93ntDd6J26qmty/LlaBTqBB3sDcm/IVZJdZJGFZXaDpAbYuxakJ9y tjdevXLccflq0E3sIbcM2q2Z6VtLhKXYmyslLL4gG8SGSOg/pO1OfSHAcCXCqeA7 At/9QUEtdU7nQaPpu9HGbxdsa/935l/89u4u4h/hixxceTf0SpuLTg== =UVSd -----END PGP SIGNATURE-----

p5pRT commented 20 years ago

From @timj

Our (closed source) Perl program has now reached 10.000 lines\, and I could not reproduce the problem with a small demo. So this report will probably not help anybody reproduce the problem\, sorry for that.

I had a similar problem in our 150\,000 line (!) application a couple of weeks ago. The problem turned out to be that when the eval completed the object destructors are called and one of the destructors itself included an eval. This eval overwrote the $@ from the main eval which caused the Error module to think that there had been an error but that the error had no content.

Localizing $@ in the object destructor fixed the problem.

See fault http://rt.cpan.org/NoAuth/Bug.html?id=3291 that I reported for the Error module.

[actually in our case we were using Error and the destructor was using a try {} block\, the fix was to add

local $@;

to sub try {} in Error.pm]

Hope this helps.

Tim Jenness

p5pRT commented 20 years ago

From rick.delaney@rogers.com

On Thu\, Sep 04\, 2003 at 03:24:19PM -0000\, Michael Jacob3 wrote:

Our problem is that the $@ variable stops working. We have a large eval{} in a testcase. The 14th test creates a new object. If I place a die() before that test it works as it should\, $@ will have the value I gave to die(). If I place a die() after test 14\, $@ will be '' (empty string) after the eval.

You are likely trapping dies with eval in your object's DESTROY method. For example:

eval { my $x = bless []\, 'Foo'; die 1; 1; } or print "died: '$@'\n";

sub Foo::DESTROY { eval { 2 }; }

This prints (on 5.8.0):

died: ''

The eval in DESTROY resets $@ to "" since it doesn't die.

On 5.6.1 I get a warning:

died: '1 at ./evalbug.pl line 4. '

but not on 5.8.0.

Please let us know if this is your problem. Tickets 17650 and 831 appear to be the same issue.

-- Rick Delaney rick.delaney@rogers.com

p5pRT commented 20 years ago

From Michael.Jacob3@de.ibm.com

Thanks Rick\, thanks Tim\,

this sounds as it c(sh)ould be the problem. I will search all modules we use for DESTROY subs on monday\, no feedback from me means I found one ;)

But I think\, we'll stick to my workaround. Patching a CPAN module on ourselfes is nothing our project managers will want to hear ;). BTW: Tels supposed we release our code to the public---sorry\, no go. We're (as usual) working for a customer\, and he pays us to make the code for him...

/mfg/ Michael Jacob

############################################################ Phone: +49-69-6645-3623 (internal: *134-3623) Mobile: +49-172-6350425 ############################################################ Other company\, product or service names may be trademarks or service marks of others.

Rick Delaney (via RT) \perlbug\-followup@perl\.org on 2003-09-05 12:19:45

Please respond to perlbug-followup@perl.org

To: Michael Jacob3/Germany/IBM@IBMDE cc: Subject: Re: [perl #23723] $@ empty after die in eval{}

On Thu\, Sep 04\, 2003 at 03:24:19PM -0000\, Michael Jacob3 wrote:

Our problem is that the $@ variable stops working. We have a large eval{} in a testcase. The 14th test creates a new object. If I place a die() before that test it works as it should\, $@ will have the value I gave to die(). If I place a die() after test 14\, $@ will be '' (empty string) after the eval.

You are likely trapping dies with eval in your object's DESTROY method. For example:

eval { my $x = bless []\, 'Foo'; die 1; 1; } or print "died: '$@'\n";

sub Foo::DESTROY { eval { 2 }; }

This prints (on 5.8.0):

died: ''

The eval in DESTROY resets $@ to "" since it doesn't die.

On 5.6.1 I get a warning:

died: '1 at ./evalbug.pl line 4. '

but not on 5.8.0.

Please let us know if this is your problem. Tickets 17650 and 831 appear to be the same issue.

-- Rick Delaney rick.delaney@rogers.com

p5pRT commented 20 years ago

@rgs - Status changed from 'new' to 'resolved'

Perl / perl5