Zombie Processes Are Eating Your Memory | Hacker News Reader

Zombie Processes Are Eating Your Memory

randomascii.wordpress.com

128 pointsjanvdberg28 comments

The author mentions CcmExec.exe a million times without explaining it. A bit of searching reveals that it's part of the Change and Configuration Management system in MS Systems Management Server (https://blogs.msdn.microsoft.com/jonathanh/2004/05/27/ccmexe...). That's why he alludes to most folks not seeing it unless they are on a corporate managed machine.

Good catch - I should have explained that, especially since I didn't know what it was initially. Fixed.

Yes, this is part of System Center Configuration Manager. A required client when deploying software, and updates to corporate machines.

> Synaptics driver leaked memory whenever a process was created

Funny! I found out the same issue last week and ended up just uninstalling the driver (not sure how permanent that is, but I'd like to think it is). I thought I was going crazy - why I was hitting pagefile after 28 days of uptime but only using around 8/32 real GB of memory! I loaded up the ram viewer tool and was aghast - hundreds of thousands of zombie processes! Death by a thousand cuts!

I guess that Synaptics driver was triply bad. I could see the memory leak in its process, and I could see the CPU usage it was triggering, but at the time I did not realize it was creating zombies. Wow.

Thank god, cant wait to try this out! My windows always feels enormously sluggish and memory seems to dissipate soon after reboot. It has been my biggest gripe with my lenovo y700 laptop and at times it has actually frozen for couple minutes after opening from sleepmode(or quickstart, the one that powers off). Really unbearable and been thinking of buying new one(or just using my work MBP even more).

UPDATE: Umm.. After spending some time getting my Visual Studio to build the FindZombieHandles-project (pre-built binary would have been nice) it immediately exists not enabling me to see all the zombie processes. I don't know how to code C# and can't really afford spending time to change the termination based on say pressing Esc-key.

You can find the worst suspects from Task Manager -> Details -> add handles column.

Or you can run the findhandles program from a command prompt; probably easiest to get VS to open the project folder for you then shift-right-click to open cmd or powershell.

The repo has prebuilt binaries now

The binaries don't work for me. When I run as a privileged (admin) user I get:

Some process names may be missing. 0 total zombie processes. No zombies found. Maybe all software is working correctly, but I doubt it. More likely the zombie counting process failed for some reason. Please try again. Pass -verbose to get full zombie names.

That happens sometimes. I don't know why.

Interesting. On my machine, Razer mouse drivers (RzSDKService.exe) seem to be leaking 2 handles every second.

Bad driver, time to remove it.

If you could complain to Razer first - maybe on twitter - that would be helpful.

Running it on my machine tells me:

> 0 total zombie processes. No zombies found. Maybe all software is working correctly, but I doubt it. More likely the zombie counting process failed for some reason. Please try again.

Looks like Creative Cloud leaks handles. Two and a half days uptime, no app updates in Creative Cloud and it had ~16,700 open handles.

Sounds like a potential DoS. Just create an delete processes never freeing the handle. And the offending process is not easily found by the average user.

Has anyone had an iOS device lose battery really fast, only lasting for less than a day, until you reboot and everything is fine again?

I recently did the backup, factory reset, and restore trick. Fixed our perf and battery life issues.

Maybe iOS needs a defrag util.

No, but I've got one that abruptly went from several days of charge to about 4 hours, at the same time that the TouchID sensor failed. Reboot was the first thing I tried. Wipe-and-reload was the next.

  "I don’t know why zombie processes consume that much RAM,
   but it’s probably because there should never be enough of
   them for that to matter."

Wow, I am surprised the complete breakdown in the logic there. It's almost like saying the cart is in front of the donkey because the donkey doesn't matter. It's easy enough to find out why but the OP author never bothers to. And also the answer is normally covered in any reasonable undergrad operating systems class.

Am I becoming an old curmudgeon or is understanding operating systems just not seen as necessary these days?

I think the logic makes sense. Presumably the thinking is that zombie processes take up 64KBytes apiece because there aren't enough of them, in general, to make it worth doing the work to make them take up less.

No that is entirely wrong, if the RAM wasn't necessary it would be freed regardless of how much it was. No person who writes production grade kernels just leaves memory hanging around because it's not worth cleaning it up (and certainly not every time a process exits).

The reason the memory is retained is so that it can be reported to the parent process why the process died (e.g. normal exit (error code 0), or failure, or killed by signal, etc), and retain enough information for simple diagnostic purposes. It is for that reason that page table mappings (for the little memory that is retained) and private data (for process exit status etc) is kept.

Sure. It's not that there's NO reason for it. But if the kernel writers thought there'd be lots of them, they would do something to reduce the amount of memory - eg, apply some data compression method to them, at least once they've been around a while (so that there would be no performance impact in typical usage).

I have a strong suspicion that the minimum process size on Windows NT is 64kB (between kernel and user pages, for Intel platforms anyway). So if you didn't treat a zombie process as "just another process" for management purposes you'd have to start having all sorts of exceptions in some very base level code (page tables, scheduler, system statistics and reporting, etc etc) just to clean up after other people who can't or won't code properly. I just can't see a kernel engineer agreeing that this was a sane thing to do (I can image how someone with a temperament like Linus would respond!).

Could be. But if it were a really big issue, I'd think that the minimum process size could be reduced, which might be a useful change in any case. After all, on the first Unix system I used, 64K was the MAXIMUM process size...

The point is that there are always tradeoffs, whose resolution is affected by how important an issue is perceived to be.

Sure they would. If zombie processes were everywhere, they'd put the effort in. How much space do you need to store info about a zombie process? It's probably 4 bytes: the exit code. I think that's all the info you get on Windows. That's the sort of thing they could do. Pack a bunch of them into one page or something perhaps? Or maybe just have 1 page each - and then it's still taking up 4KBytes rather than 64KBytes.

But zombie processes aren't everywhere. Typically they exist briefly and then get cleaned up. So even if they could take up 4 bytes, nobody's bothered writing the code to make them do that, because what's the point? If they take up 64KBytes it's just not a very pressing problem.

I don't have the Windows kernel source code but I strongly suspect that they could reduce the memory used by zombie processes if they thought it was important. The only operations that I am aware of that can be performed on a zombie process are CloseHandle, WaitForSingleObject, and GetProcessExitCode. The page tables and private memory shouldn't be needed for that.

I'm curious as to what you think the 64 KB of memory is actually needed for?

> Am I becoming an old curmudgeon or is understanding operating systems just not seen as necessary these days?

What you've written doesn't even rate "curmudgeon" status, it's just silly. I suggest that you read the author's work a little more thoroughly and then question whether your assumption that the author does not understand operating systems is correct.

Reply on news.ycombinator.com