Re: looking for a memory problem

On Thu, 19 Jul 2012 09:43:12 +1000, Shane Stanley said: >> But you can prepare your code slowly, in a way that supports both. ex: >> - replace all use of NSAllocateCollectable with malloc/free >> - change 'retain' to 'strong' in property declarations >> - replace CFMakeCollectable with CFBridging

Re: looking for a memory problem

On 19/07/2012, at 1:35 AM, Sean McBride wrote: > But you can prepare your code slowly, in a way that supports both. ex: > - replace all use of NSAllocateCollectable with malloc/free > - change 'retain' to 'strong' in property declarations > - replace CFMakeCollectable with CFBridgingRelease > - r

Re: looking for a memory problem

On Jul 18, 2012, at 12:45 AM, Martin Hewitson wrote: > On 18, Jul, 2012, at 03:07 AM, Charles Srstka > wrote: > >> On Jul 17, 2012, at 11:31 AM, Martin Hewitson wrote: >> >>> On 17, Jul, 2012, at 05:42 PM, Sean McBride wrote: >>> On Tue, 17 Jul 2012 12:30:39 +0200, Martin Hewitson said:

Re: looking for a memory problem

On Wed, 18 Jul 2012 11:03:31 +1000, Shane Stanley said: >> writing for GC and ARC is not so different, and you can even switch >over slowly > >Could you elaborate on what you mean by "switch over slowly"? I think I >understand the idea if one is coming from manual reference counting, but >I though

Re: looking for a memory problem

On 18, Jul, 2012, at 03:07 AM, Charles Srstka wrote: > On Jul 17, 2012, at 11:31 AM, Martin Hewitson wrote: > >> On 17, Jul, 2012, at 05:42 PM, Sean McBride wrote: >> >>> On Tue, 17 Jul 2012 12:30:39 +0200, Martin Hewitson said: >>> This started to appear during the process of going fro

Re: looking for a memory problem

On 18, Jul, 2012, at 04:17 AM, Martin Wierschin wrote: >> So my potential solution for this is: >> >> NSSpellChecker *checker = [NSSpellChecker sharedSpellChecker]; >> __block NSRange range = NSMakeRange(0, 0); >> while (range.location < [aString length]) { >> >> dispatch_sync(dispatch_get_m

Re: looking for a memory problem

Hi Martin, The issue exists in "[pool drain]" part of code. Hope these links might help you: http://developer.apple.com/library/mac/#technotes/tn2124/_index.html http://stackoverflow.com/questions/7194586/help-with-crash-log Regards, Lakshmi On 17-Jul-2012, at 4:00 PM, Martin Hewitson wrote:

Re: looking for a memory problem

> So my potential solution for this is: > > NSSpellChecker *checker = [NSSpellChecker sharedSpellChecker]; > __block NSRange range = NSMakeRange(0, 0); > while (range.location < [aString length]) { > >dispatch_sync(dispatch_get_main_queue(), ^{ > range = [checker checkSpellingOfString:aS

Re: looking for a memory problem

On Jul 17, 2012, at 11:31 AM, Martin Hewitson wrote: > On 17, Jul, 2012, at 05:42 PM, Sean McBride wrote: > >> On Tue, 17 Jul 2012 12:30:39 +0200, Martin Hewitson said: >> >>> This started to appear during the process of going from GC to non-GC. >> >> What do you mean "non-GC"? I strongly sug

Re: looking for a memory problem

On 18/07/2012, at 1:42 AM, Sean McBride wrote: > writing for GC and ARC is not so different, and you can even switch over > slowly Could you elaborate on what you mean by "switch over slowly"? I think I understand the idea if one is coming from manual reference counting, but I thought GC was e

Re: looking for a memory problem

On 17 Jul 2012, at 18:10, Martin Hewitson wrote: > So my potential solution for this is: > > NSSpellChecker *checker = [NSSpellChecker sharedSpellChecker]; > __block NSRange range = NSMakeRange(0, 0); > while (range.location < [aString length]) { > >dispatch_sync(dispatch_get_main_queue(),

Re: looking for a memory problem

So my potential solution for this is: NSSpellChecker *checker = [NSSpellChecker sharedSpellChecker]; __block NSRange range = NSMakeRange(0, 0); while (range.location < [aString length]) { dispatch_sync(dispatch_get_main_queue(), ^{ range = [checker checkSpellingOfString:aString

Re: looking for a memory problem

On 17, Jul, 2012, at 05:26 PM, Fritz Anderson wrote: > >> Could the problem be that I'm using the shared spell checker on multiple >> threads? > > YES. At least it's a very big item on your list of problems. I haven't found > any documentation that affirmatively says NSSpellChecker is thread

Re: looking for a memory problem

On 17, Jul, 2012, at 05:42 PM, Sean McBride wrote: > On Tue, 17 Jul 2012 12:30:39 +0200, Martin Hewitson said: > >> This started to appear during the process of going from GC to non-GC. > > What do you mean "non-GC"? I strongly suggest going from GC to ARC, not from > GC back to the stone-ag

Re: looking for a memory problem

On Tue, 17 Jul 2012 12:03:49 -0400, Charlie Dickman said: >Never mind. It originates in Xcode 4 and I don't use Xcode 4. Then I suggest staying with GC. Why do you want to switch away from GC? Yes, it's deprecated, but so is Xcode 3, so -- Sean

Re: looking for a memory problem

On Tue, 17 Jul 2012 11:52:56 -0400, Charlie Dickman said: >What is ARC and where can I read learn about it? Googling "ARC Cocoa" should find you your answer. Here's a starting point:

Re: looking for a memory problem

Never mind. It originates in Xcode 4 and I don't use Xcode 4. On Jul 17, 2012, at 11:52 AM, Charlie Dickman wrote: > What is ARC and where can I read learn about it? > > On Jul 17, 2012, at 11:42 AM, Sean McBride wrote: > >> On Tue, 17 Jul 2012 12:30:39 +0200, Martin Hewitson said: >> >>> This

Re: looking for a memory problem

On 17 Jul 2012, at 10:26 AM, Fritz Anderson wrote: > How many claims (… container insertions …) on an object does _your_ code > make…? And here's an example of the kind of thinking I was advising you against. That containers almost always retain their contents is a detail in the container cla

Re: looking for a memory problem

What is ARC and where can I read learn about it? On Jul 17, 2012, at 11:42 AM, Sean McBride wrote: > On Tue, 17 Jul 2012 12:30:39 +0200, Martin Hewitson said: > >> This started to appear during the process of going from GC to non-GC. > > What do you mean "non-GC"? I strongly suggest going from

Re: looking for a memory problem

On Tue, 17 Jul 2012 12:30:39 +0200, Martin Hewitson said: >This started to appear during the process of going from GC to non-GC. What do you mean "non-GC"? I strongly suggest going from GC to ARC, not from GC back to the stone-age retain-release. Although quite different 'under the hood', wri

Re: looking for a memory problem

On 17 Jul 2012, at 9:39 AM, Martin Hewitson wrote: > 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 po

Re: looking for a memory problem

On Jul 17, 2012, at 9:39 AM, Martin Hewitson wrote: > @property (retain) NSArray *words; > > NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init]; > > NSArray *someWords = [self > generateABunchOfAutoReleasedObjectsInAnAutoreleasedArray]; You may be doing something wrong in -generateABu

Re: looking for a memory problem

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]; NSArr

Re: looking for a memory problem

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

Re: looking for a memory problem

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

Re: looking for a memory problem

Have you tried using the zombies instrument? On 17 Jul 2012, at 11:30, 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

looking for a memory problem

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 er