in reply to Adventures in Debugging a Perl/Tk Game

I disagree with some of your analysis. @$av= (); vs. $av= [ ]; only matters if you are leaking references to the original (anonymous) array (such as via circular references). Your "fix" reduces the impact of the leak that makes the unreferenced anonymous array not get destroyed.

But I'm not particularly surprised to find unreferenced things not being destroyed when using Tk. When I've used Tk I've had to be careful to not create a lot of anonymous things because it appeared that Tk was prone to preventing things from being destroyed. Part of this may have been due to the problem of closures causing Perl to create its own circular references but I thought there was more to it than that. But having bugs in ref counting and related stuff is almost assured when you have that volume of XS code.

- tye        

Replies are listed 'Best First'.
Re^2: Adventures in Debugging a Perl/Tk Game (other leak)
by liverpole (Monsignor) on Jan 16, 2008 at 20:35 UTC
    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$..$/
[reply]
[d/l]
[select]

      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]

In Section Meditations