Re: Live_Objects behavior depends on garbage collection timing

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

On Wed, Jul 14, 2004 at 02:44:57PM -0700, Siamak Pazirandeh wrote:
> 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.

I suspect perl more than Class::DBI at the moment.

> 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.

Can you test with http://search.cpan.org/~nwclark/perl-5.8.5-RC2/ ?
I won't have time today.

Tim.

> 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.