Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can not catch die exception thrown in tie handler #12367

Open
p5pRT opened this issue Aug 31, 2012 · 3 comments
Open

Can not catch die exception thrown in tie handler #12367

p5pRT opened this issue Aug 31, 2012 · 3 comments

Comments

@p5pRT
Copy link

p5pRT commented Aug 31, 2012

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

Searchable as RT114678$

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2012

From @jimav


An exception thrown from a tied variable handler can not be caught.
The application is unconditionally terminated.
At least so it seems!

If true, it is a severe limitation on the possible robustness
of applications which use tied variables to access something
which might encounter an error or timeout.

#!/usr/bin/perl
use strict; use warnings;

package Tie​::MyTie;
sub TIESCALAR { my $class=shift; return bless [], $class; }
sub FETCH { die "FETCH throwing an error" }

package main;

our $x;
tie $x, 'Tie​::MyTie', 42;

# This eval should catch the exception, no?
my $val = eval '$x'; # dies here (really dead)
warn "caught exception​:$@​" if $@​;

warn "Expecting to get here\n";



Flags​:
  category=core
  severity=medium


Site configuration information for perl 5.14.2​:

Configured by Debian Project at Fri Aug 10 21​:43​:06 UTC 2012.

Summary of my perl5 (revision 5 version 14 subversion 2) configuration​:
 
  Platform​:
  osname=linux, osvers=2.6.42-26-generic, archname=x86_64-linux-gnu-thread-multi
  uname='linux allspice 2.6.42-26-generic #41-ubuntu smp thu jun 14 17​:49​:24 utc 2012 x86_64 x86_64 x86_64 gnulinux '
  config_args='-Dusethreads -Duselargefiles -Dccflags=-DDEBIAN -Dcccdlflags=-fPIC -Darchname=x86_64-linux-gnu -Dprefix=/usr -Dprivlib=/usr/share/perl/5.14 -Darchlib=/usr/lib/perl/5.14 -Dvendorprefix=/usr -Dvendorlib=/usr/share/perl5 -Dvendorarch=/usr/lib/perl5 -Dsiteprefix=/usr/local -Dsitelib=/usr/local/share/perl/5.14.2 -Dsitearch=/usr/local/lib/perl/5.14.2 -Dman1dir=/usr/share/man/man1 -Dman3dir=/usr/share/man/man3 -Dsiteman1dir=/usr/local/man/man1 -Dsiteman3dir=/usr/local/man/man3 -Duse64bitint -Dman1ext=1 -Dman3ext=3perl -Dpager=/usr/bin/sensible-pager -Uafs -Ud_csh -Ud_ualarm -Uusesfio -Uusenm -Ui_libutil -DDEBUGGING=-g -Doptimize=-O2 -Duseshrplib -Dlibperl=libperl.so.5.14.2 -des'
  hint=recommended, useposix=true, d_sigaction=define
  useithreads=define, usemultiplicity=define
  useperlio=define, d_sfio=undef, uselargefiles=define, usesocks=undef
  use64bitint=define, use64bitall=define, uselongdouble=undef
  usemymalloc=n, bincompat5005=undef
  Compiler​:
  cc='cc', ccflags ='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
  optimize='-O2 -g',
  cppflags='-D_REENTRANT -D_GNU_SOURCE -DDEBIAN -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include'
  ccversion='', gccversion='4.6.3', gccosandvers=''
  intsize=4, longsize=8, ptrsize=8, doublesize=8, byteorder=12345678
  d_longlong=define, longlongsize=8, d_longdbl=define, longdblsize=16
  ivtype='long', ivsize=8, nvtype='double', nvsize=8, Off_t='off_t', lseeksize=8
  alignbytes=8, prototype=define
  Linker and Libraries​:
  ld='cc', ldflags =' -fstack-protector -L/usr/local/lib'
  libpth=/usr/local/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib /usr/lib
  libs=-lgdbm -lgdbm_compat -ldb -ldl -lm -lpthread -lc -lcrypt
  perllibs=-ldl -lm -lpthread -lc -lcrypt
  libc=, so=so, useshrplib=true, libperl=libperl.so.5.14.2
  gnulibc_version='2.15'
  Dynamic Linking​:
  dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-Wl,-E'
  cccdlflags='-fPIC', lddlflags='-shared -O2 -g -L/usr/local/lib -fstack-protector'

Locally applied patches​:
 


@​INC for perl 5.14.2​:
  /home/jima/local/lib/perl/5.14.2
  /home/jima/local/lib/perl
  /home/jima/local/share/perl/5.14.2
  /home/jima/local/share/perl
  /home/jima/lib/perl
  /etc/perl
  /usr/local/lib/perl/5.14.2
  /usr/local/share/perl/5.14.2
  /usr/lib/perl5
  /usr/share/perl5
  /usr/lib/perl/5.14
  /usr/share/perl/5.14
  /usr/local/lib/site_perl
  .


Environment for perl 5.14.2​:
  HOME=/home/jima
  LANG=en_US.UTF-8
  LANGUAGE=
  LD_LIBRARY_PATH=/home/jima/local/lib
  LOGDIR (unset)
  PATH=/home/jima/bin​:/home/jima/local/bin​:/home/jima/jima_tools/bin​:/opt/libreoffice3.6/program​:/usr/bin​:/bin​:/usr/sbin​:/sbin​:/usr/bin/X11​:/usr/local/bin​:/usr/local/sbin​:/usr/games​:.
  PERL5LIB=/home/jima/local/lib/perl​:/home/jima/local/share/perl​:/home/jima/lib/perl
  PERL_BADLANG (unset)
  SHELL=/bin/bash

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2012

From @cpansprout

On Thu Aug 30 21​:45​:36 2012, jimav wrote​:

-----------------------------------------------------------------
An exception thrown from a tied variable handler can not be caught.
The application is unconditionally terminated.
At least so it seems!

If true, it is a severe limitation on the possible robustness
of applications which use tied variables to access something
which might encounter an error or timeout.

#!/usr/bin/perl
use strict; use warnings;

package Tie​::MyTie;
sub TIESCALAR { my $class=shift; return bless [], $class; }
sub FETCH { die "FETCH throwing an error" }

package main;

our $x;
tie $x, 'Tie​::MyTie', 42;

# This eval should catch the exception, no?
my $val = eval '$x'; # dies here (really dead)
warn "caught exception​:$@​" if $@​;

warn "Expecting to get here\n";

Try​:

  my $val;
  eval '$val = $x';

The eval is returning the $x itself, and the assignment outside the eval
is calling FETCH.

However, there is something fishy going on, as eval does appear to
return a different value here​:

$ perl -le' print \$x; print \do{$x}; print \eval{$x}; print \eval q|$x|'
SCALAR(0x826d90)
SCALAR(0x826d90)
SCALAR(0x8039f0)
SCALAR(0x826db0)

So I suspect something needs fixing, but I’m not sure exactly what.

This may be related to #105910.

--

Father Chrysostomos

@p5pRT
Copy link
Author

p5pRT commented Aug 31, 2012

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants