According to instruments, this seems to be working fine. Thanks.
On Oct 22, 2011, at 12:42 PM, Jean-Daniel Dupas wrote:
> 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 ([email protected])
>>
>> 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 [email protected]
>
> -- Jean-Daniel
>
>
>
>
_______________________________________________
Cocoa-dev mailing list ([email protected])
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 [email protected]
