Your choice of language. Go.

List<object> myList = new List<object>();
for (int i = 0; i < int.MaxValue; i++)
    myList.Add(new object());

 var exportBody = "";

//you can't leak in a managed language, but you can fill that fucker right the hell up
for (var i=0; i < fullDataRecords.length; i++) {
   var _record = fullDataRecords[i];
   for (var key in _record) {
      exportBody += _record[key] +' | ';
   }
}

mott555:

List<object> myList = new List<object>();
for (int i = 0; i < int.MaxValue; i++)
    myList.Add(new object());

In an ideal language, object would be a zero-width struct, which would make the last line of that increment length and do nothing else.

void TrimLeft(char *s)
{
    char *n = new char[strlen(s)];
    char *p = n;
    do {
        if (*s != ' ')
            *p++ = *s;
        ++s;
    } while (*s);
    strcpy(s,n);
    delete[ n;
}

void foo(vector input)
{
    for (vector::iterator i = input.begin(), end = input.end(); i != end; ++i)
    {
        try {
            TrimLeft(*i);
        } catch (...) {} /* BUGID 17839 */
    }
}

Oldie but goldie (in JS) :

 // init my shiny ajax page
 function initPage() {

  // setup event handlers
  $("#foobuttontop").click(function() { doFoo("top"); });
  $("#foobuttonbottom").click(function() { doFoo("bottom"); });
  // ...

  // all handlers are set up - and we're do- oh, wait, we'll still have to do some preprocessing involving this one really huge object...
  var hugeObject = createHugeObject();
  hugeObject.doPreprocessing();

  // alright. NOW we're really done. Good thing we just stored the huge object in a local variable so it can be GCed now...
 }

PSWorx:

Oldie but goldie (in JS) :

 

Explain to the incompetent dummies how this is a memory leak.

Because I don't see it.

I guess some JS implementations reference the huge object in the closures of the event handlers.

dhromed:

PSWorx:

Oldie but goldie (in JS) :

 

Explain to the incompetent dummies how this is a memory leak.

Because I don't see it.

 

 

ammoQ:

I guess some JS implementations reference the huge object in the closures of the event handlers.

dhromed:

PSWorx:

Oldie but goldie (in JS) :

 

Explain to the incompetent dummies how this is a memory leak.

Because I don't see it.

 

 

According to ECMAScript spec, all conforming implementations have to. This is so you can do stuff like

 function makeClosure() {
  var a = 5;
  return function(x) {
   eval(x); // no explicit reference to 'a' here ...
  };
 }

 var closure = makeClosure();
 closure("console.info(a)"); // ... still prints 5.

... that's not saying people haven't found some clever heuristics to work around that problem by today.

The How-smart-is-my-garbage-collector test:

class WidgetContainer;

class Widget
{
  private:
    int id;
    WidgetContainer *owner;

  public:
    Widget(int n, WidgetContainer *wc)
    {
      id = n;
      owner = wc
    }
}

class WidgetContainer
{

  private:

    List<Widget> widgets;



  public:

    void add(Widget w)
    {
      widgets.add(w);
    }
}



void test()
{
  WidgetContainer wc = new WidgetContainer();

  for (int i = 0; i < 1000000; i++) {
    wc.add(new Widget(i, &wc));
  }
}

I think most modern runtimes will figure this one out, but I'm not 100% positive on that.

curtmack:

I think most modern runtimes will figure this one out, but I'm not 100% positive on that.

You mean the circular references? Isn't that the whole point of using garbage collectors and not reference counting?

I choose VB.NET. Because it's on this machine.

Public Class LeakEverything

Public Event Generic()
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click

For i As Integer = 0 To 10000
Dim that As New Thing()
AddHandler Me.Generic, AddressOf that.HandleGenericEvent
Next
GC.Collect()'Just to make sure...

End Sub

End Class

Public Class Thing

Private m_junk As Byte()
Public Sub New()

ReDim m_junk(1024)

End Sub
Public Sub HandleGenericEvent()

'Do Nothing

End Sub

End Class

It's more subtle if the byte array is removed, of course.

PSWorx:

According to ECMAScript spec, all conforming implementations have to. This is so you can do stuff like...<snip&rt;

That's awesome and terrifying and and I don't even need to read the rest of the thread to vote that up as "best subtle memory leak". #slowclap

savar:

<snip&rt;

What the fuck is that? "Right than"? There's a preview tab for a reason.

Ben L.:

mott555:

List<object> myList = new List<object>();
for (int i = 0; i < int.MaxValue; i++)
    myList.Add(new object());

In an ideal language, object would be a zero-width struct, which would make the last line of that increment length and do nothing else.

Sorry, but you need to account for new object() != new object().

The following lists are different:

listA = new List();
listA.Add(new object());
listA.Add(new object());

listB = new List();
item = new object();
listB.Add(item);
listB.Add(item);

savar:

PSWorx:

According to ECMAScript spec, all conforming implementations have to. This is so you can do stuff like...<snip&rt;

That's awesome and terrifying and and I don't even need to read the rest of the thread to vote that up as "best subtle memory leak". #slowclap

You don't have to use JS regularly, do you? :) Everyone that's ever written any large script in JS should know that all variable definitions are implicitly moved to the top of the enclosing function. If you don't, you don't know the basics of the language you're using and you've definitely never used JSLint.

PSWorx:

Oldie but goldie (in JS) :

 // init my shiny ajax page
 function initPage() {

  // setup event handlers
  $("#foobuttontop").click(function() { doFoo("top"); });
  $("#foobuttonbottom").click(function() { doFoo("bottom"); });
  // ...

  // all handlers are set up - and we're do- oh, wait, we'll still have to do some preprocessing involving this one really huge object...
  var hugeObject = createHugeObject();
  hugeObject.doPreprocessing();

  // alright. NOW we're really done. Good thing we just stored the huge object in a local variable so it can be GCed now...
 }

I assume here the intention is that doFoo is a function local to initPage, otherwise this won't actually work in Firefox since if it can't find any uses of local variables in nested functions it won't bother saving the scope.

 

for (i = int.MinValue; i <= int.MaxValue; i++)
new byte[int.MaxValue];

Nobody said I was good at subtlety.

ekolis:

for (i = int.MinValue; i <= int.MaxValue; i++)
new byte[int.MaxValue];

Nobody said I was good at subtlety.

That doesn't leak any memory. It just makes a lot of garbage for the GC to pick up.

NeilRashbrook:

PSWorx:

Oldie but goldie (in JS):

 // init my shiny ajax page
 function initPage() {

  // setup event handlers
  $("#foobuttontop").click(function() { doFoo("top"); });
  $("#foobuttonbottom").click(function() { doFoo("bottom"); });
  // ...

  // all handlers are set up - and we're do- oh, wait, we'll still have to do some preprocessing involving this one really huge object...
  var hugeObject = createHugeObject();
  hugeObject.doPreprocessing();

  // alright. NOW we're really done. Good thing we just stored the huge object in a local variable so it can be GCed now...
 }

I assume here the intention is that doFoo is a function local to initPage, otherwise this won't actually work in Firefox since if it can't find any uses of local variables in nested functions it won't bother saving the scope.

Indeed. You'd need to have something that directly or indirectly equates to using eval in the scope of initPage for that scope to qualify to 'always' be retained, e.g., eval itself or the string based versions of setTimout and setInterval.

English:

(Enter a memory leak, stage right.)

MEMORY LEAK: Ahem! Good sirs, I do beg your pardon, but I will be absconding with some of your memory.

(MEMORY LEAK absconds with 4 GIGABYTES of RAM)

CHORUS: O where is our RAM? O where is our RAM? O where O where O where O where O where... is our poor RAM?

Nothing quite beats the power of memory leaks driven by string interning deep inside a library.

ekolis:

English:


CHORUS: O where is our RAM? O where is our RAM? O where O where O where O where O where... is our poor RAM?

Rammy, Rammy, Rammy Ram -- and it went, wherever I, Did Go....

Ben L.:

Your choice of language. Go.

 

That's not much of a choice.

dkf:

Nothing quite beats the power of memory leaks driven by string interning deep inside a library.

 

That is so hot.

dhromed:

dkf:

Nothing quite beats the power of memory leaks driven by string interning deep inside a library.

 

That is so hot.

What could be dirty about interning your string deep inside a library until it leaks?

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/22.0b4/source/firefox-22.0b4.source.tar.bz2

Maciejasjmj:

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/releases/22.0b4/source/firefox-22.0b4.source.tar.bz2

 

Nobody's been able to find it for years, so that must mean it's pretty subtle.