Re: Live_Objects behavior depends on garbage collection timing

[prev] [thread] [next] [Date index for 2004/07/14]

From: Siamak Pazirandeh
Subject: Re: Live_Objects behavior depends on garbage collection timing
Date: 21:44 on 14 Jul 2004
Tim,

> running:
> 
> 	do {
> 	    if (my $cd=Music::CD->retrieve(1)) {
> 		warn $cd->year;
> 	    }
> 	    if (my $cd=Music::CD->retrieve(2)) {
> 		warn $cd->year;
> 	    }
> 	    1;
> 	};
>         1;  # line 36 in my script
> 	warn "END\n";
> 
> produces:
> 
> 	DESTROY Music::CD=HASH(0x8352790) at x line 36
> 	DESTROY Music::Artist=HASH(0x8352a1c) at x line 36
> 	DESTROY Music::CD=HASH(0x835ef0c) at x line 36
> 	END
> 	DESTROY Music::Artist=HASH(0x8392f24) at x line 0
> 

I think we agree that the bug is likely within Class::DBI. Somehow a ref to the Artist object is internally retained, once the cd object is "fleshed". The test has the same result in 5.8.0.

Max
	

On Wed, Jul 14, 2004 at 04:29:13PM +0100, Tim Bunce wrote:
> On Mon, Jul 12, 2004 at 07:17:49PM -0700, Siamak Pazirandeh wrote:
> > Tim,
> >  Here is a self contained example, with sql dumps, packages, calling script, and output.
> 
> Thanks.
> 
> > do {
> >     if (my $cd=Music::CD->retrieve(1)) {
> >         $cd->year;
> >         1;
> >     }
> >     1;
> > };
> 
> I've not got to the bottom of it yet but...
> 
> > $VAR1 = {
> >           'Music::Artist|artistid=1' => bless( {
> >                                                  'artistid' => '1'
> >                                                }, 'Music::Artist' ),
> >           'Music::CD|artistid=1' => undef
> >         };
> 
> Note that the reference that's being "held" is not to the Music::CD
> object that was fetched by the code but to a Music::Artist object
> fetched when the Music::CD object was 'fleshed' due to calling year().
> 
> On a separate but related topic and after adding:
> 
> 	sub Music::DBI::DESTROY { Carp::carp "DESTROY @_" }
> 
> running:
> 
> 	do {
> 	    if (my $cd=Music::CD->retrieve(1)) {
> 		warn $cd->year;
> 	    }
> 	    if (my $cd=Music::CD->retrieve(2)) {
> 		warn $cd->year;
> 	    }
> 	    1;
> 	};
>         1;  # line 36 in my script
> 	warn "END\n";
> 
> produces:
> 
> 	DESTROY Music::CD=HASH(0x8352790) at x line 36
> 	DESTROY Music::Artist=HASH(0x8352a1c) at x line 36
> 	DESTROY Music::CD=HASH(0x835ef0c) at x line 36
> 	END
> 	DESTROY Music::Artist=HASH(0x8392f24) at x line 0
> 
> showing that although $cd has limited scope in the code, the lifespan
> extends until the statement after the do loop returns.
> 
> I'm using perl 5.6.1 right now. I don't have time to try that with
> perl 5.8.x at the moment. Perhaps someone else can.
> 
> 
> Summary so far: perl has issues with the lifespan of references,
> but I don't think that's the cause of items remaining in the
> Live_Objects cache (that's more likely a separate perl bug or
> something with Class::DBI, or the modules it uses, holding a ref).
> 
> Gott'a go...
> 
> Tim.

(message missing)

Re: Live_Objects behavior depends on garbage collection timing
Siamak Pazirandeh 21:44 on 14 Jul 2004

Generated at 11:35 on 01 Dec 2004 by mariachi v0.52