I only glanced over the details of your problem, so forgive me if this is way off.
I solved the memory ballooning issue in a background app by posting an "NSApplicationDefined" NSEvent (with zeros for all the arguments), which causes the NSApplication loop to return from -nextEventMatchingMask and pop the autorelease pool. In your case, you could post this event after processing a batch of files before your process goes back to sleep. On Oct 22, 2011, at 9:53 AM, "Mr. Gecko" <grmrge...@gmail.com> wrote: > Hello, I have a problem with 10.7 where when you drag files to a view which > accepts files, it'll crash because of a leak of some sort. This is triggered > by my CFRunLoopObserver which I've written because operations which is done > in the background never had the autorelease pool drained until the UI was > brought up and my application's UI was hardly ever brought up. > > Let me explain the setup. First is my run loop observer. > > static NSAutoreleasePool *pool = nil; > > void runloop(CFRunLoopObserverRef observer, CFRunLoopActivity activity, void > *info) { > if (activity & kCFRunLoopEntry) { > if (pool!=nil) [pool drain]; > pool = [NSAutoreleasePool new]; > } else if (activity & kCFRunLoopExit) { > [pool drain]; > pool = nil; > } > } > > CFRunLoopObserverContext context = {0, self, NULL, NULL, NULL}; > CFRunLoopObserverRef observer = CFRunLoopObserverCreate(kCFAllocatorDefault, > kCFRunLoopEntry | kCFRunLoopExit, YES, 0, runloop, &context); > CFRunLoopAddObserver(CFRunLoopGetCurrent(), observer, kCFRunLoopDefaultMode); > > This is what I used to get around the memory never being released while the > UI was not shown. Because my application deals in files and has watchers for > files, whenever a watcher found a file and read it, that file would stay in > the ram until you bought up the UI. I know I could of added my own > NSAutoReleasePool for that part, but that also means other parts of my code > will have to add that as well as well as some notifications which was way > more work/code than wanted. > > Now my NSView is in a NSStatusItem which will be used for when someone drags > to that menu in the menubar, it'll allow them to drop the file and have the > file be uploaded. My NSView registers for files with the following line. > > [self registerForDraggedTypes:[NSArray > arrayWithObject:NSFilenamesPboardType]]; > > Even if I just do that and do not listen for drag operations, it'll crash > because of my loop observer creating and draining that autorelease pool. All > I can say is that all of this was working in 10.6 and now is broken in 10.7. > > Here is the crash stack so you can see what I'm talking about. > Thread 0 Crashed:: Dispatch queue: com.apple.main-thread > 0 libobjc.A.dylib 0x00007fff946d800b (anonymous > namespace)::AutoreleasePoolPage::pop(void*) + 385 > 1 com.apple.CoreFoundation 0x00007fff92527f75 > _CFAutoreleasePoolPop + 37 > 2 com.apple.Foundation 0x00007fff8ecfa057 > -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 275 > 3 com.apple.Foundation 0x00007fff8ed7dc0a > -[NSRunLoop(NSRunLoop) runUntilDate:] + 66 > 4 com.apple.AppKit 0x00007fff8e4a2523 > NSCoreDragTrackingProc + 3477 > 5 com.apple.HIServices 0x00007fff94279b0d DoTrackingMessage + > 357 > 6 com.apple.HIServices 0x00007fff9427b42c > CoreDragMessageHandler + 461 > 7 com.apple.CoreFoundation 0x00007fff925ebbb9 > __CFMessagePortPerform + 729 > 8 com.apple.CoreFoundation 0x00007fff924f911c > __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 44 > 9 com.apple.CoreFoundation 0x00007fff924f8e4b __CFRunLoopDoSource1 > + 155 > 10 com.apple.CoreFoundation 0x00007fff9252f587 __CFRunLoopRun + 1895 > 11 com.apple.CoreFoundation 0x00007fff9252eae6 CFRunLoopRunSpecific > + 230 > 12 com.apple.HIToolbox 0x00007fff9843c3d3 > RunCurrentEventLoopInMode + 277 > 13 com.apple.HIToolbox 0x00007fff9844363d > ReceiveNextEventCommon + 355 > 14 com.apple.HIToolbox 0x00007fff984434ca > BlockUntilNextEventMatchingListInMode + 62 > 15 com.apple.AppKit 0x00007fff8e0ca3f1 _DPSNextEvent + 659 > 16 com.apple.AppKit 0x00007fff8e0c9cf5 -[NSApplication > nextEventMatchingMask:untilDate:inMode:dequeue:] + 135 > 17 com.apple.AppKit 0x00007fff8e0c662d -[NSApplication run] > + 470 > 18 com.apple.AppKit 0x00007fff8e34580c NSApplicationMain + > 867 > > Some of my options are: > 1. Forget about the memory usage and remove my runloop observer. > 2. Find a new way to prevent this memory issue from happening. > 3. Have apple fix Lion. > 4. Do whatever you suggest I do. > > If you can think of how I can fix this issue, please let me know. If you need > a test subject, I am willing to point you to my source > code._______________________________________________ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/davekeck%40gmail.com > > This email sent to davek...@gmail.com _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com