Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

A potential memory leak in the Finder System
An anonymous tipster sent in the following tidbit:
With top running in terminal, I was looking at the amount of memory consumed by the Finder. I observed that when cycling through a Folder with pictures (.bmp, .tiff) and preview is on, the Finder consumes a lot of memory and does not release it. By cycling with the arrow keys through some folders, the Finder consumed more than 500MB of memory. In order to release the memory, I had to do a kill -9 for the Finder process.
I was intrigued and did some similar experiments on my machine. Here are a few key columns from the "top" output for the Finder at a normal usage level, about 30 minutes after startup:
PID COMMAND       %CPU  RPRVT  RSHRD  RSIZE   SIZE
484 Finder 0.0% 5.83M 27.9M 30.7M 153M
I then browsed a few of my iPhoto archive folders in column-view mode with preview enabled (I did this for no more than a minute or so), and re-ran top. I was quite surprised to see:
PID COMMAND       %CPU  RPRVT  RSHRD  RSIZE   SIZE
484 Finder 0.0% 540M 18.5M 66.9M 776M
I went back to my normal routine and checked "top" again about 45 minutes later and found that, as the tipster claimed, the memory had not been released.

So if you've been browsing a number of folders containing images in the Finder, you might want to take a look at "top" (or Process Viewer in the Finder) to see how much memory the Finder is consuming, and restart it if necessary. Restarting the Finder will return things to normal, at least until you browse additional image-laden folders.

For those more technical than I, is this truly a memory leak in the Finder? It seems like it to me, but perhaps I'm not understanding the column headings in the "top" output correctly. Thoughts, anyone?
    •    
  • Currently 0.00 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (0 votes cast)
 
[13,237 views]  

A potential memory leak in the Finder | 20 comments | Create New Account
Click here to return to the 'A potential memory leak in the Finder' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
RSIZE and VSIZE
Authored by: Auricchio on Nov 08, '02 09:57:18AM

VSIZE is the total amount of VM the process is using. It costs you swap space and perhaps some time paging in stuff for the process.

RSIZE is the resident size in memory, which impacts the system more directly than VSIZE. This figure doesn\'t consider whether those pages are wired in memory (not pageable), just that they\'re currently resident. They may also be shared with other processes (e.g. as shared-library code), so they\'re getting more use than you might otherwise think.

If it\'s a leak, of course, it\'s a bug. You might report it to Apple and someone will check on it.



[ Reply to This | # ]
RSIZE and VSIZE
Authored by: Halo1 on Nov 09, '02 12:29:02PM

FWIW, VSIZE does not necessarily cost you swap space. In previous version of Mac OS X, e.g. the VSIZE of classic was always 1 GB. This didn't mean that it allocated one gig of swap space however, simply that it's virtual address space was 1 GB large.

Most of the time the VSIZE indicates the amount of memory that the application and its library occupy and allocated. However, if you allocate memory without using it, it doesn't cost you anything (no swap is created for it or so).



[ Reply to This | # ]
Almost...
Authored by: erm on Nov 08, '02 10:13:35AM

Everyone needs to bear in mind that some of those numbers are for shared memory (which is shared between a numberof running applications), and paged memory (swapped to disk). I came up with similar numbers while testing, and my PBG3 does not have 750MB of memory like top was reporting for the finder, but things were still humming along.

But I would agree that something is amiss and the finder should un-bloat itself after a while.



[ Reply to This | # ]
Exlplains VueScan Crashes?
Authored by: kerim on Nov 08, '02 10:27:37AM

When I do batch scanning with VueScan I've often had crashes. Occasionally it actually brings down the coresystemservices. Hamrik Software says this must be a bug with Apple. Could this be related?



[ Reply to This | # ]
memory leak
Authored by: kirkmc on Nov 08, '02 10:36:33AM

I'm very interested in this, since, on my 400 Mhz iMac, I see the memory being used up, bit by bit, and must regularly reboot (at least once a day, if not more).

So, let me speculate.

After reading the tip, I tried to browse a few folders containing images, using the previews in column view. My Finder memory, as shown in top, went up, but just slightly. Then, when I browsed from one folder to another, many times, through many folders, it went up much more. My guess it that it has something to do with the Finder recording all of the browsing so when you click the forward or back button it goes to the next folder quickly. This could explain how, after many hours, the Finder slowly eats up memory.

Can anyone confirm that this might be the case?

Anyway, one way to purge that cache would be to quit the Finder, and that does, indeed, lower the Finder memory in top...

Kirk



[ Reply to This | # ]
RE:memory leak
Authored by: englabenny on Nov 08, '02 11:20:07AM

well, I think the memory goes simply to remember file structure and incons/info for files browsed on the HD, which could explain both why pics use much memory and also why just browsing "regular" files might inflate finder's memory useage..



[ Reply to This | # ]
Basic UNIX Fact:
Authored by: porkchop_d_clown on Nov 08, '02 11:22:21AM

When an application asks for more virtual memory than it currently has, the operating system enlarges that applications memory space. When the application frees that memory, the operating system DOES NOT shrink the application again - it leaves the virtual memory space (not actual RAM!) assigned to the application on the assumption that it is likely to want that memory again later.

This is pretty fundamental to how UNIX works. I would only worry if you went back later, browsed those photos a second or third time and the Finder got even larger.



[ Reply to This | # ]
Basic UNIX Fact:
Authored by: taikahn on Nov 08, '02 01:09:58PM

Anyone wanna try this?

I think its not a bug --- unix apps like apache exhibit extremely similiar issues --- but then again, I always have to reboot/restart for apache to "get back to normal" ---



[ Reply to This | # ]
run MacJanitor?
Authored by: Reddog on Nov 08, '02 03:07:05PM

When I\'ve seen my memory usage climb for no apparent reason, I\'ve been running the MacJanitor weekly script. Seems to reclaim a lot of memory.



[ Reply to This | # ]
run MacJanitor?
Authored by: kirkmc on Nov 08, '02 05:46:21PM

You can also run the following in the terminal:

sudo periodic weekly

It is only the weekly maintenance script that frees memory.

Kirk



[ Reply to This | # ]
you're lucky...
Authored by: imacusr on Nov 08, '02 03:22:11PM

Browsing through my Pictures folder in the Finder almost always winds up crashing the Finder, which then restarts itself but over time becomes less and less stable until I finally have to restart completely.

The few times that this *doesn't* happen, the odds are about 50-50 that the machine will simply kernel-panic while browsing the folder.

10.2 needs some stability work, and the Finder needs to just be taken out and shot.



[ Reply to This | # ]
you're lucky...
Authored by: GaelicWizard on Nov 08, '02 04:05:56PM
Use PathFinder, F.K.A. SNAX, it's a great finder-replacement. I love it. it's made by CocoaTech. (i think it's done by just one guy.) It's a great app. JP

[ Reply to This | # ]
Finder crashes on large photo
Authored by: wfolta on Nov 08, '02 04:58:03PM

Same for me. In my Pictures directory I have thousands of photos and when I browse the folder in icon view with the largest size icons, it's only a matter of time before the Finder crashes and restarts.

It doesn't seem to bother anything else -- UNIX you know -- but I hate it when Finder comes back up and all of my many carefully minimized windows come up non-minimized and I have to click-click-click to put them back into the Dock.



[ Reply to This | # ]
you're lucky...
Authored by: nalyd on Nov 09, '02 10:40:45AM

If you are having this kind of stability problem, your machine has some serious hardware problem. Or maybe there is some data corruption in your photo collections, the last time I saw this behviour was in 10.1.x with some messed-up files.

Also (esp. if you are running an older G4) make sure your firmware is up to date. 10.2 does freeze frequently on a pre-quicksilver G4 using older firmware, but updating to the latest clears it right up.



[ Reply to This | # ]
you're lucky...
Authored by: malvolio on Nov 09, '02 11:22:28PM

Definitely you have a problem that is not inherent in 10.2. Earlier today I spent a good deal of time browsing in a file with over 11,000 (!) jpeg images. I was in column view with preview mode active. Memory usage rose, naturally, but there were no slowdowns or Finder crashes (or any other crashes, for that matter).
This was on a 500 MHz G3 iMac with 768 MB of RAM.



[ Reply to This | # ]
Ummmm...
Authored by: porkchop_d_clown on Nov 10, '02 03:41:07PM

I would seriously consider fsck'ing your disk (or using a commercial tool like Disk Warrior).

I don't think the problem is the Finder - I think your file system is damaged.



[ Reply to This | # ]
Explanation
Authored by: Anonymous on Nov 08, '02 05:33:23PM
The Finder isn't actually allocating the memory, it is mapping it. There is a difference, but the end result is the same (and a bug).

When you browse a set of images, the Finder-- likely QuickTime or something related to the imaging infrastructure-- is asking the Mach memory manager to map the image data into memory. There is a difference between mapping a file into memory and allocating a hunk of memory and reading the file into that memory. Namely, when the system needs to page out a hunk of mapped memory (the image is no longer being previewed in the finder), it can simply dump the data in memory as the file already exists on disk-- there is no need to write the data out to the swapfile.

Because the current generation of machines are 32 bits, a process cannot simply map every file on disk into memory. As each file is mapped, it is assigned a virtual address within the process. If the process [Finder] tries to map in more than 4GB (likely less because of a series of reserved addresses) into memory, it will exceed the 32bit address space and crash (unless it does some fairly esoteric mach level memory interrupt handling).

Obviously, Finder shouldn't crash in this case. The problem is that the Finder is not releasing the mapped memory.

Keep in mind that simply because a file is mapped into memory, it may not actually be occupying a physical hunk of memory. By mapping a file, the mach memory manager simply reserves a set of addresses to correspond to the contents of that file. The contents of the file are not physically read into RAM until the program tries to actually read the data.

All of this (except the Finder crashing part) is the reason why you'll often see applications claiming that they are using tons of RAM listed in the VSIZE column. Just because it is listed does not mean the app has actually used that much physical memory + swap space.

The mach memory manager can also preallocate memory. For example, PhotoShop could choose to "allocate" 2GB of RAM from the mach memory manager. This only means that PhotoShop has indicated to mach that it wants a 2GB address space, not 2GB of memory. As PhotoShop writes data into that 2GB of memory, the mach memory manager will take care of ensuring that the memory is backed by physical RAM and, as needed, swaps the oldest accessed pages out to disk.


[ Reply to This | # ]
Explanation
Authored by: pmccann on Nov 08, '02 07:34:59PM

Thanks for the clear explanation, Bill. Now if we can just corral the henny-penny's of the Mac OS X world and force them to read what you've written then the number of posts claiming that the sky is falling should diminish dramatically.

One fairly convincing way to underline the disparity between "give me abstract addresses for this much space" versus "give me this much space" is to crank up classic, and then compare the VSIZE given by "top" with the number of VM pages that have actually been made on the system. This demo usually has a calming effect on those distressed by the large VSIZE's that are visible in OS X's "top".

Cheers,
Paul



[ Reply to This | # ]
Speaking of memory leaks -- lookupd?
Authored by: marmoset on Nov 11, '02 07:51:17AM

Has anyone else noticed lookupd consuming (and not releasing) large amounts of memory? I've sometimes noticed lookupd consuming hundreds of megs of RPRVT memory after doing lots of name resolutions (I run a news aggregator, sendmail, and Apache, all of which are doing lots of DNS lookups.) After a couple of days, I've sometimes seen lookupd with a half gig of memory allocated. Restarting lookupd (via "sudo /System/Library/SystemConfiguration/Kicker.bundle/Resources/restart-lookupd") frees up several hundred megs of VM.



[ Reply to This | # ]
Speaking of memory leaks -- lookupd?
Authored by: sjk on Sep 19, '03 05:09:35PM

Noticed your post since I'm currently trying to debug a excessive memory usage problem with lookupd on my 10.2.6 iBook 600.

If I run fs_usage on the process it spits out lines like this (among others) every second or two:

11:04:08 stat private/etc/hosts 0.000095 lookupd
11:04:08 open private/etc/hosts 0.000034 lookupd

I have a generic configuration (e.g. no changes to LookupOrder). I don't know what's normal for this because this is my only Mac OS X system but I'm sure it shouldn't be consuming as much memory as it does over a relatively short time. My search for answers continues...



[ Reply to This | # ]