Re: Live_Objects behavior depends on garbage collection timing

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

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.