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 <martin.hewit...@aei.mpg.de>
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 <3tothe...@comcast.net> 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 (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:
>>> https://lists.apple.com/mailman/options/cocoa-dev/3tothe4th%40comcast.net
>>>
>>> This email sent to 3tothe...@comcast.net
>>
>> Charlie Dickman
>> 3tothe...@comcast.net
>>
>>
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
