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

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...).