I also encounter this annoying issue, and also try something like that, but as
you can see, it does not works.
I workaround this issue by periodically posting application defined event that
trigger an event loop, and make the framework drain the autorelease pool.
Somewhere in my application initialization:
[NSTimer scheduledTimerWithTimeInterval:60 target:self
selector:@selector(drainAutoreleasePool:) userInfo:nil repeats:YES];
And the draining method:
- (void)drainAutoreleasePool:(NSTimer *)aTimer {
// We hope it does not have side effects (other than draining the pool)
NSEvent *evt = [NSEvent otherEventWithType:NSApplicationDefined
location:NSMakePoint(0, 0)
modifierFlags:0
timestamp:CFAbsoluteTimeGetCurrent()
windowNumber:0 context:nil subtype:0 data1:0
data2:0];
[NSApp postEvent:evt atStart:NO];
}
Le 22 oct. 2011 à 15:53, Mr. Gecko a écrit :
> 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/devlists%40shadowlab.org
>
> This email sent to devli...@shadowlab.org
-- Jean-Daniel
_______________________________________________
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
