• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: looking for a memory problem
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: looking for a memory problem


  • Subject: Re: looking for a memory problem
  • From: Martin Hewitson <email@hidden>
  • Date: Tue, 17 Jul 2012 16:39:58 +0200

Actually, to follow up a little. This is what I was doing:

Within the operation's main I create a bunch of autoreleased objects and put this in an autoreleased array. In (very) rough code I do:

@property (retain) NSArray *words;

NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];

NSArray *someWords = [self generateABunchOfAutoReleasedObjectsInAnAutoreleasedArray];
self.words = myAutoreleasedArray;

// inform delegate that we have a list of words ready for collection
[self.delegate performSelectorOnMainThread:  withObject:self waitUntilDone:NO];

[pool drain];

So I must not be understanding something (likely) because I thought that the autoreleased objects get retained when I add them to the autoreleased array. Then when I set the array to the property, it gets retained and so draining the pool shouldn't result in releasing the objects, should it?

And, in fact, with some judicious log statements I see the objects don't get released when the pool drains, only much later when the document is closed.

And yet, if I don't assign the autoreleased array to the property then I never see the crash and I see the objects being deallocated when the pool drains.

I'd be grateful if somebody could point out the (stupid) mistake. Currently I'm stumped.

Just occasionally I see a different backtrace like this:
* thread #8: tid = 0x3703, 0x00007fff98d4afde libobjc.A.dylib`objc_release + 14, stop reason = EXC_BAD_ACCESS (code=13, address=0x0)
    frame #0: 0x00007fff98d4afde libobjc.A.dylib`objc_release + 14
    frame #1: 0x00007fff98d4a2b0 libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 464
    frame #2: 0x00007fff97624a62 CoreFoundation`_CFAutoreleasePoolPop + 34
    frame #3: 0x00007fff92fdbb70 AppKit`-[NSSpellChecker _checkSpellingOfString:startingAt:language:wrap:inSpellDocumentWithTag:wordCount:reconnectOnError:] + 1379
    frame #4: 0x00007fff92fdbbd0 AppKit`-[NSSpellChecker checkSpellingOfString:startingAt:language:wrap:inSpellDocumentWithTag:wordCount:reconnectOnError:] + 75
    frame #5: 0x00007fff92fdbd06 AppKit`-[NSSpellChecker checkSpellingOfString:startingAt:] + 55
    frame #6: 0x00000001000b6925 TeXnicle`-[NSString(Spelling) listOfMisspelledWords] + 342 at NSString+Spelling.m:51
    frame #7: 0x00000001000b6b2e TeXnicle`-[TPSpellCheckFileOperation main] + 227 at TPSpellCheckFileOperation.m:68
    frame #8: 0x00007fff9586fbb6 Foundation`-[__NSOperationInternal start] + 684
    frame #9: 0x00007fff958773d1 Foundation`__block_global_6 + 129
    frame #10: 0x00007fff99ecbf3d libdispatch.dylib`_dispatch_call_block_and_release + 15
    frame #11: 0x00007fff99ec80fa libdispatch.dylib`_dispatch_client_callout + 8
    frame #12: 0x00007fff99ec923e libdispatch.dylib`_dispatch_worker_thread2 + 304
    frame #13: 0x00007fff93784ceb libsystem_c.dylib`_pthread_wqthread + 404
    frame #14: 0x00007fff9376f1b1 libsystem_c.dylib`start_wqthread + 13

Could the problem be that I'm using the shared spell checker on multiple threads?

So after some googling I came across this post:

http://www.cocoabuilder.com/archive/cocoa/132829-nsspellchecker-crashes-after-64k-words.html

It seems to hint at similar problems, but not exactly the same.

Oh well, more digging to do.

Cheers,

Martin



On 17, Jul, 2012, at 04:09 PM, Martin Hewitson <email@hidden> wrote:

> Thanks to all. Due to the various clues and tips I finally tracked down the problem. I was creating a bunch of autoreleased objects within an autorelease pool of an NSOperation then storing them. But of course, when the pool is drained they all get released and boom!
>
> Thanks,
>
> Martin
>
> On 17, Jul, 2012, at 03:29 PM, Charlie Dickman <email@hidden> wrote:
>
>> I've seen this kind of thing before when I have released an object that was allocated in the autorelease pool. Have a go over of the objects you release and make sure that you own them when you release them.
>>
>> On Jul 17, 2012, at 6:30 AM, Martin Hewitson wrote:
>>
>>> Dear list,
>>>
>>> I've been trying to track down a crash that happens sometimes when a document is closed in my NSPersistentDocument based app. This started to appear during the process of going from GC to non-GC. But it only happens after an undetermined number of document closes and reopens. The error message I get in the debugger is
>>>
>>> * thread #1: tid = 0x2103, 0x00007fff8f614e90 libobjc.A.dylib`objc_msgSend + 16, stop reason = EXC_BAD_ACCESS (code=1, address=0x10)
>>>  frame #0: 0x00007fff8f614e90 libobjc.A.dylib`objc_msgSend + 16
>>>  frame #1: 0x00000001098147d0
>>>  frame #2: 0x00007fff8f61a03c libobjc.A.dylib`(anonymous namespace)::AutoreleasePoolPage::pop(void*) + 434
>>>  frame #3: 0x00007fff938c8915 CoreFoundation`_CFAutoreleasePoolPop + 37
>>>  frame #4: 0x00007fff8b8bb6cf Foundation`-[NSAutoreleasePool drain] + 154
>>>  frame #5: 0x00007fff90146115 AppKit`-[NSApplication run] + 634
>>>  frame #6: 0x00007fff903c2244 AppKit`NSApplicationMain + 867
>>>  frame #7: 0x0000000100001574 TeXnicle`start + 52
>>>
>>>
>>> I've tried disabling various parts of the app trying to isolate where the issue might be.
>>>
>>> Could anyone offer any advice on how I might better track this down? Perhaps using instruments in some way?
>>>
>>> Cheers,
>>>
>>> Martin
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> Cocoa-dev mailing list (email@hidden)
>>>
>>> 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:
>>>
>>> This email sent to email@hidden
>>
>> Charlie Dickman
>> email@hidden
>>
>>





_______________________________________________

Cocoa-dev mailing list (email@hidden)

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:

This email sent to email@hidden

  • Follow-Ups:
    • Re: looking for a memory problem
      • From: Fritz Anderson <email@hidden>
    • Re: looking for a memory problem
      • From: Ken Thomases <email@hidden>
References: 
 >looking for a memory problem (From: Martin Hewitson <email@hidden>)
 >Re: looking for a memory problem (From: Charlie Dickman <email@hidden>)
 >Re: looking for a memory problem (From: Martin Hewitson <email@hidden>)

  • Prev by Date: Re: looking for a memory problem
  • Next by Date: Re: looking for a memory problem
  • Previous by thread: Re: looking for a memory problem
  • Next by thread: Re: looking for a memory problem
  • Index(es):
    • Date
    • Thread