Disappearing object #6133

p5pRT · 2002-12-08T04:50:21Z

Migrated from rt.perl.org#18951 (status was 'rejected')

Searchable as RT18951$

p5pRT · 2002-12-08T04:50:21Z

From @Juerd

Created by @Juerd

Good morning (It has to be morning *somewhere*),

With DBIx::Simple, users of at least Perl 5.6.1 and 5.8.0 get the following
error message:
Fatal error: Can't call method "disconnect" on an undefined value at
/usr/share/perl5/DBIx/Simple.pm line 123 during global destruction.

Even with a lot of stripping down, I wasn't able to get rid of this error.
Here's the small version. Note that this is a stripped down version of the
module and a script that uses it.

#!/usr/bin/perl -w
package DBIx::Simple::Stripped;
use DBI;

sub connect { bless { dbi => DBI->connect(@_[1..$#_]) }, $_[0] }

sub die {
printf "In die: The dbh is now: %s\n", defined $_[0]->{dbi} ? $_->[0]->{dbi} : 'undef';
return if $_[0]->{dead};
$_[0]->{dbi}->disconnect();
$_[0]->{dead} = 1;
}

sub disconnect {
printf "In disconnect: The dbh is now: %s\n", defined $_[0]->{dbi} ? $_->[0]->{dbi} : 'undef';
$_[0]->die;
}

sub DESTROY {
printf "In DESTROY: The dbh is now: %s\n", defined $_[0]->{dbi} ? $_->[0]->{dbi} : 'undef';
$_[0]->die;
}

package main;

my $db = DBIx::Simple::Stripped->connect('DBI:SQLite:foo');
sub foo { $db }

printf "In main code: The dbh is now: %s\n", defined $db->{dbi} ? $db->{dbi} : 'undef';
END { printf "In END block: The dbh is now: %s\n", defined $db->{dbi} ? $db->{dbi} : 'undef'; }
__END__

This outputs:
In main code: The dbh is now: DBI::db=HASH(0x82035ec)
In END block: The dbh is now: DBI::db=HASH(0x82035ec)
In DESTROY: The dbh is now: undef
In die: The dbh is now: undef
(in cleanup) Can't call method "disconnect" on an undefined value at
bug.pl line 10 during global destruction.

The dbh (stored in $db->{dbi}) disappears between the END block's execution
and global destruction.

Things get even more interesting when the sub foo is commented out. It then
outputs:
In main code: The dbh is now: DBI::db=HASH(0x8203658)
In END block: The dbh is now: DBI::db=HASH(0x8203658)
Use of uninitialized value in printf at bug.pl line 20.
In DESTROY: The dbh is now:
Use of uninitialized value in printf at bug.pl line 8.
In die: The dbh is now:

Lines 8 and 20 are in the form of:
printf "%s", defined $foo ? $foo : 'undef';

I don't get how that can ever warn about using an uninitialized value in
the printf call, as it should then use the defined string 'undef'. It seems
the object disappears between the defined() and its use in the second part
of the tenary operator.

I'm puzzled. Please help :)

This has only been tried on several Linux systems and one FreeBSD box.

Greets,

Juerd

P.S. For now, I'll release a version of DBIx::Simple that disconnect()s
only if the dbh is still there.

Perl Info

(I did change it. see "SECOND BOX")


Flags:
    category=core
    severity=high

Site configuration information for perl v5.6.1:

Configured by root at Sun Oct 13 20:05:59 CEST 2002.

Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
  Platform:
    osname=linux, osvers=2.4.19-gentoo-r7, archname=i686-linux
    uname='linux peanut 2.4.19-gentoo-r7 #3 smp mon aug 12 03:36:57 CET 686 i686 celeron (coppermine) genuineintel gnulinux '
    config_args='-des -Dprefix=/usr -Darchname=i686-linux -Duselargefiles -Dd_dosuid -Dlocincpth=  -Dd_semctl_semun -Di_gdbm -Di_db -Di_ndbm'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
  Compiler:
    cc='cc', ccflags ='-fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64',
    optimize='-march=pentium3 -O3 -pipe -fomit-frame-pointer',
    cppflags='-fno-strict-aliasing'
    ccversion='', gccversion='3.2', 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, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='cc', ldflags =' -L/usr/local/lib'
    libpth=/usr/local/lib /lib /usr/lib
    libs=-lnsl -lndbm -lgdbm -ldb -ldl -lm -lc -lcrypt -lutil
    perllibs=-lnsl -ldl -lm -lc -lcrypt -lutil
    libc=/lib/libc-2.2.5.so, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags='-rdynamic'
    cccdlflags='-fpic', lddlflags='-shared -L/usr/local/lib'

Locally applied patches:
    


@INC for perl v5.6.1:
    /usr/lib/perl5/5.6.1/i686-linux
    /usr/lib/perl5/5.6.1
    /usr/lib/perl5/site_perl/5.6.1/i686-linux
    /usr/lib/perl5/site_perl/5.6.1
    /usr/lib/perl5/site_perl
    .


Environment for perl v5.6.1:
    HOME=/home/juerd
    LANG (unset)
    LANGUAGE (unset)
    LD_LIBRARY_PATH (unset)
    LOGDIR (unset)
    PATH=/bin:/usr/bin:/opt/vmware/bin:/opt/rar/bin:/usr/X11R6/bin:/opt/blackdown-jre-1.3.1/bin:/usr/qt/3/bin:/usr/kde/3.1/bin:/usr/kde/3.1/bin:/usr/local/bin:/opt/bin
    PERL_BADLANG (unset)
    SHELL=/bin/bash


SECOND BOX:

Perl -V output:

Summary of my perl5 (revision 5.0 version 6 subversion 1) configuration:
  Platform:
    osname=freebsd, osvers=4.5-release-p3, archname=i386-freebsd
    uname='freebsd xs0.xs4all.nl 4.5-release-p3 freebsd 4.5-release-p3 #5: tue apr 23 10:22:45 cest
2002 cor@xs0.xs4all.nl:usrsrcsyscompilexs0 i386 '
    config_args='-sde -Dprefix=/usr/local -Darchlib=/usr/local/lib/perl5/5.6.1/mach -Dprivlib=/usr/local/lib/perl5/5.6.1 -Dman3dir=/usr/local/lib/perl5/5.6.1/man/man3 -Dsitearch=/usr/local/lib/perl5/site_perl/5.6.1/mach -Dsitelib=/usr/local/lib/perl5/site_perl/5.6.1 -Ui_malloc -Ui_iconv -Dccflags=-DAPPLLIB_EXP="/usr/local/lib/perl5/5.6.1/BSDPAN" -Ui_gdbm -Dusemymalloc=n'
    hint=recommended, useposix=true, d_sigaction=define
    usethreads=undef use5005threads=undef useithreads=undef usemultiplicity=undef
    useperlio=undef d_sfio=undef uselargefiles=define usesocks=undef
    use64bitint=undef use64bitall=undef uselongdouble=undef
  Compiler:
    cc='cc', ccflags ='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.6.1/BSDPAN" -fno-strict-aliasing -I/usr/local/include',
    optimize='-O -pipe ',
    cppflags='-DAPPLLIB_EXP="/usr/local/lib/perl5/5.6.1/BSDPAN" -fno-strict-aliasing -I/usr/local/include'
    ccversion='', gccversion='2.95.3 20010315 (release) [FreeBSD]', 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, usemymalloc=n, prototype=define
  Linker and Libraries:
    ld='cc', ldflags ='-Wl,-E  -L/usr/local/lib'
    libpth=/usr/lib /usr/local/lib
    libs=-lgdbm -lm -lc -lcrypt -lutil
    perllibs=-lm -lc -lcrypt -lutil
    libc=, so=so, useshrplib=false, libperl=libperl.a
  Dynamic Linking:
    dlsrc=dl_dlopen.xs, dlext=so, d_dlsymun=undef, ccdlflags=' '
    cccdlflags='-DPIC -fPIC', lddlflags='-shared  -L/usr/local/lib'

Characteristics of this binary (from libperl):
  Compile-time options: USE_LARGE_FILES
  Built under freebsd
  Compiled at Nov 26 2002 01:49:55
  @INC:
    /usr/local/lib/perl5/site_perl/5.6.1/mach
    /usr/local/lib/perl5/site_perl/5.6.1
    /usr/local/lib/perl5/site_perl/5.005/i386-freebsd
    /usr/local/lib/perl5/site_perl/5.005
    /usr/local/lib/perl5/site_perl
    /usr/local/lib/perl5/5.6.1/BSDPAN
    /usr/local/lib/perl5/5.6.1/mach
    /usr/local/lib/perl5/5.6.1
    .

p5pRT · 2002-12-08T17:25:13Z

From rick.delaney@rogers.com

Juerd (via RT) <perlbug-followup@perl.org> writes:

sub DESTROY {
printf "In DESTROY: The dbh is now: %s\n", defined $_[0]->{dbi} ? $_->[0]->{dbi} : 'undef';
^^^^^ ^^^^^^^

Two different variables.

$\_\[0\]\->die;

}

In main code: The dbh is now: DBI::db=HASH(0x82035ec)
In END block: The dbh is now: DBI::db=HASH(0x82035ec)
In DESTROY: The dbh is now: undef
In die: The dbh is now: undef
(in cleanup) Can't call method "disconnect" on an undefined value at
bug.pl line 10 during global destruction.

The dbh (stored in $db->{dbi}) disappears between the END block's execution
and global destruction.

I don't think order of destruction is guaranteed during the global phase.

Lines 8 and 20 are in the form of:
printf "%s", defined $foo ? $foo : 'undef';

Really of the form:

printf "%s", defined $foo[0] ? $foo->[0] : 'undef'

I don't get how that can ever warn about using an uninitialized value in
the printf call, as it should then use the defined string 'undef'.

Because you're referring to two different variables (see above).

--
Rick Delaney
rick.delaney@rogers.com

p5pRT · 2002-12-08T20:11:13Z

From @Juerd

printf "In DESTROY&#8203;: The dbh is now&#8203;: %s\\n"\, defined $\_\[0\]\->\{dbi\} ? $\_\->\[0\]\->\{dbi\} : 'undef';
Two different variables.

Lines 8 and 20 are in the form of:
printf "%s", defined $foo ? $foo : 'undef';
Really of the form:
printf "%s", defined $foo[0] ? $foo->[0] : 'undef'

Oops. That's very stupid of me. However, these lines were only to make
the bug report look better (I failed at that, didn't I? :).

With the corrected program, the problem is still is:

In main code: The dbh is now: DBI::db=HASH(0x82035ec)
In END block: The dbh is now: DBI::db=HASH(0x82035ec)
In DESTROY: The dbh is now: undef
In die: The dbh is now: undef
(in cleanup) Can't call method "disconnect" on an undefined value at
bug.pl line 10 during global destruction.

The dbh (stored in $db->{dbi}) disappears between the END block's execution
and global destruction.

I don't think order of destruction is guaranteed during the global phase.

That would be bad. After all, the dbh's refcount hasn't reached 0 yet.

What use is a DESTROY method if parts of your object are destroyed
before it is entered? Maybe I wanted to do another database update just
before disconnecting.

Note also that it works correctly when the sub foo { $db } is removed.
(If all occurences of $_->[0] have substituted by $_[0], that is)

If you tie() $db->{dbi}, as with this block of code after the connect():

{ package Blah; use Tie::Scalar; our @ISA = 'Tie::StdScalar';
sub TIESCALAR { bless \pop, shift } sub FETCH { printf "Being ".
"used at %s line %d\n", (caller)[1,2]; $_[0]->SUPER::FETCH; } }
{ my $foo = $db->{dbi}; tie $db->{dbi}, 'Blah', $foo }

A similar error message shows up:
(in cleanup) Can't call method "FETCH" on an undefined value at
bug.pl line 20 during global destruction.

This should, as I understand it, never happen.

I do believe this is a bug in Perl. Everything works correctly if $db
is not used in a sub.

Juerd

p5pRT · 2010-09-06T16:07:02Z

From @iabyn

(Just going through old perlbug tickets)
Perl has two types of clean up; on scope exit (including the implied
scope exit at the end of a program file), and global clean up.The former
frees lexicals etc that are going out of scope at that point, and has a
fairly predicable clean up order.

Global cleanup is of the "if all else fails" variety; it simply goes
through the
list of objects in the SV arenas, artificially reducing their refrerence
count by one. There is no guaranteed order of destruction here (and
indeed can't be, for example with mutually referenced objects).

In the case of

sub foo { $db }

this creates a closure, delaying the freeing of $db from end-of-file
scope to global cleanup.

p5pRT · 2010-09-06T16:07:03Z

@iabyn - Status changed from 'open' to 'rejected'

p5pRT closed this as completed Sep 6, 2010

p5pRT added Severity High distro-freebsd leak/refcount/malloc lexical/scope/closure type-core labels Oct 18, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Disappearing object #6133

Disappearing object #6133

p5pRT commented Dec 8, 2002

p5pRT commented Dec 8, 2002

p5pRT commented Dec 8, 2002

p5pRT commented Dec 8, 2002

p5pRT commented Sep 6, 2010

p5pRT commented Sep 6, 2010

Navigation Menu

Disappearing object #6133

Disappearing object #6133

Comments

p5pRT commented Dec 8, 2002

p5pRT commented Dec 8, 2002

From @Juerd

Created by @Juerd

p5pRT commented Dec 8, 2002

From rick.delaney@rogers.com

p5pRT commented Dec 8, 2002

From @Juerd

p5pRT commented Sep 6, 2010

From @iabyn

p5pRT commented Sep 6, 2010