How do I see the actual leaked bytes Instruments has identified for me?

I am using the Leaks instrument, and it has identified a bunch of 32 and 48 byte "Malloc" leaks. I would like to see a hex dump of some (or all) of those areas. I think if I can see what is in them I can get a better idea about what is triggering the leak.

I'm pretty sure it is a real leak.

What is the easy way to do this? Can it be done inside instruments, or do I need to run my app under instruments and also attach via lldb and hexdump from lldb? (can I attach lldb and instruments at the same time?)

If it matters I'm debugging an iPadOS app, and it is written in Swift plus ObjC, plus ObjC++, oh, and some straight C++.

Instruments doesn't save the contents of memory - it provides other methods of identifying allocations like these, which will probably be much more effective than manually inspecting the memory.

The easiest way to identify leaked untyped malloc blocks is to reproduce the leaks while running your app under Instruments's Leaks template. The Leaks instrument will identify leaks, and the Allocations instrument will record information about how your app allocates memory, including the backtraces of its calls to malloc() and siblings. From there you can inspect the list of leaked allocations and, if you're directly responsible for allocating them, see the exact line of code which performed the allocation. We document this process in detail in the Instruments help book under Find memory leaks.

If you still need to read the contents of these allocations, you can reproduce the issue while debugging your app with Xcode, then read the raw contents of any memory in your app using the Xcode memory browser (accessible via Debug -> Debug Workflow -> View Memory) or with LLDB (via the memory read command).

Thanks. I know about the stack trace, I can see where the memory was allocated, but we are allocating thousands of them per second and deallocation just slightly less then thousands per second (in the same path). So examining the actual leaked objects (in this case I think they are string fragments) seems like the best corse to track down the root cause of not deallocating them (I'm expecting one of the error paths doesn't deallocate everything it had going on, but that code is all C++ and it has been a while since I've crawled around in a big C++ mess and I figured having more information about the error state would be helpful...).

How do I see the actual leaked bytes Instruments has identified for me?
 
 
Q