64 bit apps - memory leaks that crash the system

General
1

A 32 bit app that leaks will die at 4GB (or less) before too much harm has happened - if you have more than 4GB of RAM, no problem. If you have less, then some Virtual Memory paging will happen but the OS will recover.

I’ve seen a few 64 bit apps that leak memory and take the OS down with it - in a 64 bit app the OS will happily allocate 10, 20, 30 GB or more of memory to the process, but this all gets paged out to disk and eventually the OS itself has troubles especially if you run out of disk space.

Presumably the OS should not do this, but I’ve seen it happen.

Any ideas about how to write a 64 bit app that’s a good citizen even when it goes crazy and starts leaking?

2

Have been thinking about the same issue a while ago. I have forgotten to add the NSAutoreleasePoolMBS once in a while. And some version of my app did a memory leak in Filemaker so I had to monitor Filemaker.

We could monitor the memory of our own apps. For instance, give a warning when over 5 GB and restart over 10 GB.

3

And then your user will have a project / document that needs 11 Gb and you keep restarting :slight_smile:

4

Wait hold on, let me just drag feature length movies into the Navigator.
brb filing a bug report.

5

@Tim Parnell : Don’t laugh, I’ve recently tried to drag a QT Movie of recorded Screen into Feedback… :wink: it took a while… and I was close to kill the process…

6

@Normal Palardy: of course, the numbers were examples, which need to be adjusted for each app. 10 GB should be more than enough for my app.

7

Two things come to mind:

  • Try to narrow down the memory leaks and patch them.
  • Move majorly leaky tasks to a helper application. Core Image’s RAW processor can be a leaky whatnot when asking it to export the full sized image multiple times (I’m certain it’s not my code), but by pushing this out to a helper application, it doesn’t matter any more, because once the job is completed, the helper is killed and memory freed.
8

you can have a timer check your app from time to time:

WorkingSetSize of WindowsProcessMemoryInfoMBS class:
http://www.monkeybreadsoftware.net/class-windowsprocessmemoryinfombs.shtml

or DarwinResourceUsageMBS class:
http://www.monkeybreadsoftware.net/class-darwinresourceusagembs.shtml

The problem can be if you allocate too quick that paging can’t keep up.
Or if you cause so many memory usage that system runs out of pages.

9

The problem isn’t finding and patching the memory leaks. The last one I had was a simple oversight with a DockItem where I forgot the AutoRelease thingie. I just want to make sure that such a simple bug doesn’t take down a user’s system.

10

When dealing with Apple’s APIs, you do need to pay attention to make sure that you’re not leaking memory.

If it’s a flat C API:

  • Get means you need to retain and release it when you’re done.
  • Copy & Create means you need to release it when you’re done.

If it’s Objective C:

  • init needs to be released when you’re done.
  • Retain and Release when done.

Personally I’ve only ever had bad experience with AutoRelease and avoid it like I would the plague.

11

Apple frameworks autorelease a lot of objects and if the auto release pool is missing, that’s a leak.

12

I used NSAutoreleasePoolMBS in several apps but removed it later. I got a lot users complaining my app freezes at times. It took me a long time to find out that calling NSAutoreleasePoolMBS was to blame.
I never could reproduce this on my systems but removing NSAutoreleasePoolMBSdid did resolved the freezing problems for those users.

I still have no clue why this freezing happend.

13

The NSAutoreleasePoolMBS was just an example, guys, for how fast a memory leak can happen. I forgot the dang thing and my app crashed after a couple of minutes of working.

14

[quote=314245:@Tim Parnell]Wait hold on, let me just drag feature length movies into the Navigator.
brb filing a bug report.[/quote]
You have no idea how close to the truth that is :slight_smile:

15

Good discussion all, thanks.

There should be a way to tell the OS - “I should be using no more than X GB of RAM and should not fail to service my event loop for more than Y seconds, and if I do, please terminate me”