1

I'd like to know whether anyone has a suggestion for an alternative to using runningApplications, as something like the following appears to be leaking memory:

https://openradar.appspot.com/24067155 https://github.com/bradjasper/NSRunningApplicationMemoryLeaks

- (void)applicationDidFinishLaunching:(NSNotification *)aNotification {

    [NSTimer scheduledTimerWithTimeInterval:10.0 target:self selector:@selector(checkApps:) userInfo:nil repeats:YES];

}

- (void) checkApps : (id) sender {

    @autoreleasepool {

        NSArray *appsArray = [[NSWorkspace sharedWorkspace] runningApplications];

        for (NSRunningApplication *a  in appsArray) {
            NSLog(@"%@", [a localizedName]);
        }

    }

}

Is the only option to wait until Apple provides a solution? I'm working in a sandboxed environment, so some NSTask-based alternatives may not work. Thanks in advance for any ideas.

William Gustafson
  • 526
  • 2
  • 13
  • Did you use Instruments to figure out what is leaking and why? – bbum Jan 24 '16 at 00:53
  • I ran the code as written and didn't see any accretion over time. This may be because a bug has been fixed between the release you are on and the release I'm on (I'm in the betas) or it may be some weird configuration issue; do you have zombies on or anything like it? – bbum Jan 24 '16 at 00:59
  • Instruments doesn't detect a leak, but memory allocation continually goes up and up... http://cl.ly/363F050O1k2e Zombie Objects are not enabled on my sample project. I'll have to test in the latest beta of OS X. My project is running under the public 10.11.3 (15D21) release. – William Gustafson Jan 24 '16 at 01:13
  • Of note, it seems you have to actually _do_ something with the NSRunningApplication object(s) in the appsArray (like log its localizeName or similar). Simply alloc init'ing the array from runningApplications doesn't reproduce the leak in my testing. – William Gustafson Jan 24 '16 at 01:23

2 Answers2

1

The answer to your question, is there another sandboxable option?: is no. This is how you're supposed to look for running applications.

You might try KVO (on the sharedWorkspace's runningApplications property) instead. The documentation suggests doing just that rather than what you're doing:

Instead of polling, use key-value observing to be notified of changes to this array property.

elasticthreads
  • 131
  • 1
  • It's my fault for not mentioning this, but the memory leak occurs when using KVO as well. The use of a NSTimer for this just speeds up the memory allocation. You are right though, KVO is the way to do this. – William Gustafson Jan 24 '16 at 03:06
1

After a fair amount more troubleshooting, I eventually found that the memory leak issue only occurs when building/running the app/project from Xcode (Version 7.2 (7C68)). If I build the project, and then head into Finder and manually launch the app built, memory allocation appears to stabilize.

I don't have Zombie objects enabled, and I've made no changes from the default project settings. This must be a bug within Xcode.

William Gustafson
  • 526
  • 2
  • 13