Memory usage about apptrap HOT 7 CLOSED

Hey dnicolson. Thanks for the report.

In a given week, do you delete a lot of apps? Also, do you move a lot of stuff to the trash throughout the day? I ask because AppTrap lays dormant until something happens with the trash. This definitely seems like a leak and I'm guessing it's coming from somewhere in the code relating to that.

Thanks for your help!

from apptrap.

In the few hours it took to get to 1.95GB I don't know if anything was moved to the trash. The memory usage is now at 2.31GB.

Is there anything I can do to diagnose the problem?

from apptrap.

Hmm, do you keep a lot of items in your trash folder? If so, does the memory use go down when you empty it?

from apptrap.

There were quite a few items in there:

find .Trash -type f | wc -l
  637480

After emptying the trash, the memory usage is now 4.68GB.

from apptrap.

Same for me. 1.2.2 is eating up all available memory. Both on a MBP and MP. No items in the trash at all. Returning to 1.2.1 stopped that.

from apptrap.

Every time something is happening in Trash directory, runs search for deleted apps and somewhere it's leaking..

Process:         AppTrap [6973]
Path:            /Users/wolf/Library/PreferencePanes/AppTrap.prefPane/Contents/Resources/AppTrap.app/Contents/MacOS/AppTrap
Load Address:    0x10fa7f000
Identifier:      com.KumaranVijayan.AppTrap
Version:         1.2.2 (64)
Code Type:       X86-64
Parent Process:  launchd [285]

Date/Time:       2014-10-17 16:56:45.139 +0400
OS Version:      Mac OS X 10.9.5 (13F34)
Report Version:  7

leaks Report Version:  2.0
Process 6973: 250874 nodes malloced for 51672 KB
Process 6973: 12 leaks for 768 total leaked bytes.

from apptrap.

You're correct. I've determined that it occurs every time I call contentsOfDirectoryAtPath:error:. There appears to be a memory leak in that API. I was at WWDC this year and I brought it up with an engineer and he proposed that I use contentsOfDirectoryAtURL:includingPropertiesForKeys:options:error:. Unfortunately, this also has a memory leak. I need to file a radar or two.

I think I have a design that sidesteps this entirely. The parts of the background process that touch the filesystem (using the aforementioned APIs) can be factored out into an XPC process. That way the memory leaks are contained in the XPC process which will be destroyed once the search for related files for a particular application is finished. That's a pretty substantial design change but I'm pretty sure it would fix the problem. Thoughts?

from apptrap.