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 (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

Reply via email to