Re^2: Adventures in Debugging a Perl/Tk Game (other leak)

I'm not sure if you misunderstood what I meant, or if I'm not quite following your reply.

Just in case, I'll show you a visual representation (and also because I originally thought this would make things more clear):

                                                                      
+          
                                                                      
+          
Code / Comments                    Visually
======================================================================
+========
my $ptext  = $pboard->{'text'};    pboard->text ====+
                                                    |
                                                    v
                                   ptext ====> [ (some IDs) ]
                                                                      
+          
                                                                      
+          
                                                                      
+          
                                                                      
+          
$pboard->{'text'} = [ ];           pboard->text ===> [ ]
# Now they're pointing to          ptext ==========> [ (some IDs) ]
# different things
                                                                      
+          
                                                                      
+          
                                                                      
+          
                                                                      
+          
my $id = my_create($canvas, ...);  pboard->text  ===> [ ]
push @$ptext, $id;                 ptext ===========> [ (some IDs), $i
+d ]
# But my intent was to add $id to
# $pboard->{'text'}!
[download]

Now it's clear that (some IDs) in the picture disappears (when $ptext goes out of scope at the end of the subroutine), and never gets pushed into the intended array $pboard->{'text'} (so the Canvas text is never successfully deleted).

I'm quite sure from calling show_id_hash() that the Canvas text objects were never getting deleted (even though their numeric IDs were when $ptext went out of scope). And it's also clear to me that the same text objects do get deleted when I correctly reassign $ptext to point to the anonymous array which was assigned to $pboard->{'text'} (or by emptying out the original array with @$ptext = ( )).

Does that make my intent any clearer, or do you still find something amiss?

s''(q.S:$/9=(T1';s;(..)(..);$..=substr+crypt($1,$2),2,3;eg;print$..$/

Comment on Re^2: Adventures in Debugging a Perl/Tk Game (other leak) Select or Download Code

Replies are listed 'Best First'.
Re^3: Adventures in Debugging a Perl/Tk Game (other leak) by tye (Sage) on Jan 17, 2008 at 05:04 UTC
Yes, that is clearer. Thanks. If DESTROY doesn't clean up a canvas, then that supports my impression of Tk encouraging memory leaks. If it is too difficult to have DESTROY clean up, then I would rather have DESTROY complain that I forgot to clean up. But in a programming environment with OO and where exceptions can be thrown, I've come to consider any clean up that is not done from within a destructor (DESTROY in Perl) to be a bug. Expecting people to do the equivalent of matching up malloc() and free() calls is just the perfect recipe for bugs. So I still interpret what you described as more you not successfully working around an ugly feature of Tk, even though it wasn't quite the feature I originally thought. I get the impression that it wasn't actually the leaked memory that was the problem. It sounds like the real problem was the number of objects Tk had to sift through more than the memory size of the process. But that wasn't clear to me from your description. - tye	[reply]

Replies are listed 'Best First'.

Re^3: Adventures in Debugging a Perl/Tk Game (other leak)
by tye (Sage) on Jan 17, 2008 at 05:04 UTC

Yes, that is clearer. Thanks.

If DESTROY doesn't clean up a canvas, then that supports my impression of Tk encouraging memory leaks. If it is too difficult to have DESTROY clean up, then I would rather have DESTROY complain that I forgot to clean up.

But in a programming environment with OO and where exceptions can be thrown, I've come to consider any clean up that is not done from within a destructor (DESTROY in Perl) to be a bug. Expecting people to do the equivalent of matching up malloc() and free() calls is just the perfect recipe for bugs.

So I still interpret what you described as more you not successfully working around an ugly feature of Tk, even though it wasn't quite the feature I originally thought.

I get the impression that it wasn't actually the leaked memory that was the problem. It sounds like the real problem was the number of objects Tk had to sift through more than the memory size of the process. But that wasn't clear to me from your description.

- tye

[reply]