Yes, there is more than one way to skin a cat. Use whatever methods work for
you. But keep in mind that your experiences may not be the same as others
because your code base is obviously going to be different. So I would not
recommend avoiding one tool over another just because it didn’t work
For iOS, I’ve found that setting up a test to replicate the memory leak, or
simply running tests is a great idea. Here’s where Instruments sucks. Running
on the Simulator, Instruments often drops the connection to the target. Also,
I’ve gotten Instruments files that are 30 GB, while just sett
> On May 20, 2020, at 7:03 AM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
> This line is in a method I declared like that:
>
> - (void) loadNextImageWithIndex: (unsigned long) next_index image:
> (CGImageRef *) next_image
> withProps: (CFDictionaryRef *) next_props
Off-t
I’ve had a lot of success with Instruments leaks traces. In the retain/release
world we live in, knowing the backtrace to where the object was created isn’t
enough. Instruments gives a nice UI to walk the retain/release history of an
object, and the backtrace of each retain/autorelease/release
Also, in your run scheme, enable the Diagnostics for Logging > Malloc Stack >
Live Allocations Only.
> On May 20, 2020, at 10:08 AM, Georg Seifert via Cocoa-dev
> wrote:
>
> You need to check the backtrace where the leaking object was created.
> Sometimes it points to a line that has nothing
Do NOT use Instruments.
Use the Memory Graph Debugger. It’s in your debugger console near the
breakpoint button and View Hierarchy Debugger.
Try that first.
> On May 20, 2020, at 9:03 AM, Gabriel Zachmann via Cocoa-dev
> wrote:
>
> I have a few stupid questions regarding (potential) mem
You need to check the backtrace where the leaking object was created. Sometimes
it points to a line that has nothing to do with the leak, it is just triggering
it.
g
> On 20.05.2020, at 16:03, Gabriel Zachmann via Cocoa-dev
> wrote:
>
> I have a few stupid questions regarding (potential) mem
