Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Circular references are <strike>by far the most common</strike>the canonical cause of leaks.</p> <pre><code>sub leak { my ($foo, $bar); $foo = \$bar; $bar = \$foo; } </code></pre> <p>Perl uses reference counting garbage collection. This means that perl keeps a count of what pointers to any variable exist at a given time. If the variable goes out of scope and the count is 0, the variable is cleared.</p> <p>In the example code above, <code>$foo</code> and <code>$bar</code> are never collected and a copy will persist after every invocation of <code>leak()</code> because both variables have a reference count of 1. </p> <p>The easiest way to prevent this issue is to use weak references. Weak references are references that you follow to access data, but do not count for garbage collection.</p> <pre><code>use Scalar::Util qw(weaken); sub dont_leak { my ($foo, $bar); $foo = \$bar; $bar = \$foo; weaken $bar; } </code></pre> <p>In <code>dont_leak()</code>, <code>$foo</code> has a reference count of 0, <code>$bar</code> has a ref count of 1. When we leave the scope of the subroutine, <code>$foo</code> is returned to the pool, and its reference to <code>$bar</code> is cleared. This drops the ref count on <code>$bar</code> to 0, which means that <code>$bar</code> can also return to the pool.</p> <p><strong>Update:</strong> brain d foy asked if I have any data to back up my assertion that circular references are common. No, I don't have any statistics to show that circular references are common. They are the most commonly talked about and best documented form of perl memory leaks. </p> <p>My experience is that they do happen. Here's a quick rundown on the memory leaks I have seen over a decade of working with Perl.</p> <p>I've had problems with pTk apps developing leaks. Some leaks I was able to prove were due to circular references that cropped up when Tk passes window references around. I've also seen pTk leaks whose cause I could never track down.</p> <p>I've seen the people misunderstand <code>weaken</code> and wind up with circular references by accident.</p> <p>I've seen unintentional cycles crop up when too many poorly thought out objects get thrown together in a hurry.</p> <p>On one occasion I found memory leaks that came from an XS module that was creating large, deep data structures. I was never able to get a reproducible test case that was smaller than the whole program. But when I replaced the module with another serializer, the leaks went away. So I know those leaks came from the XS.</p> <p>So, in my experience cycles are a major source of leaks. </p> <p>Fortunately, <a href="http://search.cpan.org/dist/Devel-Cycle/lib/Devel/Cycle.pm" rel="noreferrer">there is a module</a> to help track them down. </p> <p>As to whether big global structures that never get cleaned up constitute "leaks", I agree with brian. They quack like leaks (we have ever-growing process memory usage due to a bug), so they are leaks. Even so, I don't recall ever seeing this particular problem in the wild.</p> <p>Based on what I see on Stonehenge's site, I guess brian sees a lot of sick code from people he is training or preforming curative miracles for. So his sample set is easily much bigger and varied than mine, but it has its own selection bias.</p> <p>Which cause of leaks is most common? I don't think we'll ever really know. But we can all agree that circular references and global data junkyards are anti-patterns that need to be eliminated where possible, and handled with care and caution in the few cases where they make sense.</p>
    singulars
    1. This table or related slice is empty.
    1. POCommon Perl memory/reference leak patterns?
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USdaotoad
    1. USdaotoad
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POCommon Perl memory/reference leak patterns?
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COIs there anything to support circular references as the most common form? I hardly ever see the problem, but I do see people with global hashes that they never clear out.
      singulars
      1. PO
      1. USbrian d foy
    2. CO@brian d foy: Strictly speaking, that's not a memory leak, just excessive memory use. It's not a memory *leak* until the program *can't* free the memory anymore.
      singulars
      1. PO
      1. UScjm
    3. COMost people don't strictly care why their memory constantly grows slowly (or not so slowly). :)
      singulars
      1. PO
      1. USbrian d foy
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload