Instruments/Allocations inconsistent object counts when drilling down

Question

diffent OP

Created May ’16

Replies 3

Boosts 0

Participants 3

situation: app in stable state, I see 5 CoreImage objects at top level Statistics / Allocation Summary

but when I click the circle-right arrow to drill down, it only shows 2. and the memory usage total is much less

in the drill-down. has anyone seen this? which is correct?

see attached.

oh well the attacher seems to be broken.

also, if anyone at apple is listening, can you modify Instruments to read the debug symbols out of the executable directly?

rather than relying on the dSYM files? those dSYM files seem to always get lost or misplaced or deleted during clean/purge

operations that are often required during Xcode development. "if lldb can do it, you can too!" if you inherit a project where

the settings arent right to generate dSYMs, it can take a long time to find out what is wrong and get them to generate. and it seems to vary

depending on what version of Xcode the project started on and what Xcode you are using now.

Boost

Answer 1

diffent OP

May ’16

fyi, here is some more evidence of dSYM troubles:

https://www.reddit.com/r/iOSProgramming/comments/4cyrer/has_anyone_ever_gotten_stuck_in_missing_dsyms/

just google missing dSYMs, it's a big problem

0

Answer 2

QuinceyMorris OP

May ’16

Regarding Instruments:

It may not be an error, but the options for the top level summary may (in effect) be different from those for your detail view. The top level might be including all objects ever created and/or destroyed, while the detail might only be show objects still in existence at a certain time.

If you can't find an explanation, or if there might be an explanation but you think it's too confusing, then submit a bug report and attach your Instruments document.

Regarding dSYMs:

>> "if lldb can do it, you can too!"

Actually, it's always lldb, not Xcode. Xcode uses lldb as its interface to debugging generally.

As to missing debug information, it's a bit complicated. In a release build, all debugging information has been moved to a dSYM, and the executable contains nothing to help debugging, except module names and global symbols.

In a debug build, the debug information (last I heard) can be spread around multiple locations, according to the technical needs of various binary format standards. In addition, some of the combined debug information is identified by paths to the original source files, and these are absolute. That means if you inherit a project from someone else, existing debug information may not be found by default (in relation to the new paths on your Mac). There are ways of telling lldb how to relate the old and new paths, but you need to learn more about lldb commands to get proficient at this. (I'm not. I know that if I figure it out, I'll forget before the next time I need to know. But there may be tutorials you can google for.)

That means, the short answer is just to recompile the inherited project. It may take longer initially, but you'll decrease the self-inflicted pain portion of the exercise.

0

Answer 3

grzywacz OP

May ’16

As QuinceyMorris points out, the debugger has the advantage of running against a debug build, which has all the information it needs contained within the binary. Instruments almost always is run against a release build, which does not contain that information. Instead, Instruments must rely on the dSYM for both symbol and source level information.

I can't speak to the issues developers may be having generating dSYMs, but if those problems are affecting your workflow it's worth a radar against Xcode to see if we can remove this pain point.

0