When you check gather leaked memory contents in the Leaks instrument what does this do? I have a troublesome leak and thought maybe this "memory content" might be useful in tracking it down...but I can't find it!?!
The data ends up at the bottom of the stack trace in the "Extended Detail" sidebar. Un-disclose the triangle in the stack header to make it more obvious, like in the screenshot below.
Related
In visual studio I can set a breakpoint in my code and, when execution breaks, get the address of the memory I am interested in, and then put the address into the memory window to see all the memory bytes from the address onwards. Here's an example:
You can see the breakpoint hit in the middle Visual Studio window, the watch on the variable I am interested in in the bottom window that gives me the address, and I typed the address into the top window to see the memory there.
After execution hits a breakpoint in Xcode how do I view the bytes in memory from a particular address onwards?
(N.B. I have tried to search online for this but my search results are dominated by Xcode's memory usage monitor, which is not what I am after.)
As Martin R points out in his comment on my question, Eric covers exactly this in his answer to the question How to print memory in 0xb0987654 using lldb. Eric explains that Xcode has a Memory Browser window that displays the contents of a given memory addresses.
Eric mentions that we can access the memory browser by pressing ⌘⌥⇧M or through the Debug --> Debug Workflow --> View Memory menus.
He notes that there is a field in its bottom left corner where we can paste the memory address you want to inspect.
Lastly he provides a link to the documentation and to another related answer
Can someone explain what gaps in Google Chrome Inspector's Network tab represent?
The network tab shows a list of consecutively loaded resources. For the most part they overlay and/or immediately follow one another. But sometimes there is a gap, and in the case of this screenshot there's actually almost 2 seconds of a gap.
All 5 of the later loaded scripts are hosted by a third party.
If you click on the heading "Timeline" and then select "Duration", you'll get a better view of what's actually happening for each request.
If you hover over each line, you'll see a breakdown of each request, and most likely for those later ones you'll find that they have large "Blocking" values.
Edit: I should probably put a small note about what blocking is here, just in case. Blocking (as defined in the link in the next paragraph) is the amount of time between the UI thread starting the request and the HTTP GET request getting onto the wire.
Here is a good Stack Overflow question that explains what each segment means and what you can (or can't) do to improve it.
How i can view Stack content (not stack call) at visual studio 2013?
view to where ESP is pointing and below. show content at char.
Thanks for the help.
You can do this by going to Debug > Windows > Registers, get the location of ESP, and then enter this address in a Debug > Windows > Memory window. However, that will only give you the raw memory.
As OwenWengerd points out in the comments, you can simply type ESP in the address field if you're debugging native code. For some reason, this doesn't work for managed code though.
The other answer is correct for 32-bit code, however it is only "half-correct" for 64-bit code.
If you really want to see the memory at esp, then you can enter esp in the Address input box in the Memory debug window.
However, this is probably not what you want for 64-bit code. The stack is at rsp not esp.
If you enter rsp into the Address input textbox in the Memory debug window then you will see the stack memory. If you enter esp into the Address input textbox then you will see the memory at (rsp & 0x00000000ffffffff), which is probably not what you want.
You may recreate what some older DOS debuggers had like Turbo Debug, with an arranged memory pane:
Open a memory pane.
In the context menu, select 4-bytes integer (resp. 8-bytes) for a 32-bit stack (resp. 64-).
Select 1 column (or reduce the width of the pane to let only 1 column appear, whatever suits you best; also you might want to display this narrow pane under your solution explorer where it'll almost naturally have a single column)
Enter esp (resp. rsp) in the address bar.
Click on the refresh button so that the address bar reevaluates on each step.
If debugging at assembly level and stepping through some PUSHes and POPs, you should see the memory pane keep in sync.
Note: this was written with x86 or amd64 architectures in mind which aren't the only supported by VS. If you're on another architecture, adapt what you read to your CPU's own specifics i.e., open the register pane to find out your own stack pointer register name.
I am currently updating my app, and I have been facing a very strange and complex problem for the last few days. The part of the application that is problematic is made of one UITableViewController that is a list of news, and (after you click on a news) a detail view which is in fact a UICollectionView with as many details CollectionViewCells as there are news.
Each of these can have an infinite amount of elements, and are loaded 20 by 20 when the user scrolls to the bottom of the TableView (or to cell that is at the furthest position right on the CollectionView). Also, inside a DetailsCollectionViewCell, there can be another UICollectionView, containing images.
My problem is that after scrolling a few details views, after behaving normally (ie memory is allocated when I change the page, then stabilize until I change the page again, and so on), the memory allocation start to ramp up slowly but steadily, even if I stop doing anything at all. Also, the CPU usage will go to 100-120% and stay there, whatever I do, even, again, if I don't touch anything. After a while, the UICollectionView and the UITableView will not render any animation anymore, thus loosing the paging, and the inertia when scrolling, and overall resulting in a very poor user experience.
The strange thing is, I can observe these behaviours via XCode 5's Debug Navigator, but when I try to use instrument to find the source of the leaks/allocations, the allocation graph is normal, and I get 40-60 MB mem usage, no more, despite still observing the animations/paging problems.
Has anyone already met such a strange behaviour, and can someone help me in finding the cause of all this fuss ? (maybe by fixing Instruments ?)
Thank you all in advance, don't hesitate to ask me for more infos if needed !
I found the solution to my problems in the meantime.
About the difference in Memory usage between Xcode 5's Debug Navigator and Instruments, it was caused by my use of NSZombies. I have the habit of always setting them on, and that just flew off my mind... To remove them : Product > Scheme > Edit Scheme > Diagnostics > Enable Zombie Objects (just unmark it).
The cause of my CPU usage was an animation that was going on indefinitely in the background on multiple pages. The solution was to first of all stop it as soon as it is not seen/useful anymore, the optimise it by changing my approach (I was using CAAnimation and moved on to using UIView's animate function).
I think I might have pulled the trigger a bit too fast here, but hey... if this can help someone later, then it will not be a waste !
For tasks that will take more than a few seconds, a good user interface, in my opinion, should provide a progress bar along with appropriate information on the progress of the operation. (Microsoft kindly provide User Interface Guidelines on this topic, but I want a status panel that is a bit more advanced.)
The "task" class I am using is able to log messages, and if the messages are important enough (warning or error), I would like to display them on the progress panel. It would also be nice with a graphical indication when warnings or errors have occured (a warning or error icon perhaps). If there are many such messages, a text box, a list view or perhaps some report control could be appropriate here.
There could be a cancel button while the task is running, and after the task has been completed, a "View log" button would also be nice.
To summarise, I have a good idea how to implement my status panel, but I would really like some input on this. Did I miss something important? Am I going overboard on this? Are there perhaps any components like this already available out there?
For logging, you should probably actually have another higher level of error. These are the levels I usually implement (as swiped from DEC back in the 80's).
DEBUG - a very low-prioity message that the developer just put in to help diagnose what's going on in the event something goes awry.
INFORMATIONAL - No problem, just reporting progress the user might be interested in.
WARNING - Something that could possibly be an issue in some situations, but may also be just fine.
ERROR - A definite problem. The user must be informed, but the program will try to keep going.
FATAL - A problem so bad that the program can't go on.
The second is, since you are calling this a "progress panel", I assume you are planning on implementing some kind of progress bar. There has actually been a fair bit of research into progress bars. The main thing is that, whatever you do, don't let the bar get slower as it progresses. That makes it seem to drag on forever.
Lastly, it sounds like you are considering some sort of status message line. If you are looking for some good status messages, I suggest you use some of these. :-)
You have here a similar Status Panel specifications which can give you some ideas on what could be included into this kind of GUI:
In sort, define your goals and scope of this Status Panel before listing the design details.
Note: with too much options on it, you will evolve it into a "Control Panel" ;-)
You'll want to view log messages while in progress, not just at the end. If a bug occurs, it'll often be before the task is done, and the UI thinks everything is still chugging along. It can be really annoying to find this is happening, and yet the only visible log message (without going to some external file somewhere) is some random informational message far removed from the actual problem.
(I don't know whether you're already doing this, as it's not clear from your question. If you are, hats off.)
I think it's important that your main progress bar fill up exactly once, and there is always indication of progress.
I've just recently done something very similar at work. The tasks were long, with many subtasks. The interface I ended up with was a double progress bar, which were actually the first and last of a stack of progress bars.
The API is something like
StartNewTask(Caption,NumberOfSubtasks)
EndTask
SetProgress(Caption,NumberOfSubtasksFinished)
StartNewTask pushes a new bar on the stack, and EndTask pops one.
SetProgress sets the progress of the most-recently-pushed progress bar, and ripples up the changes to parent bars. For example:
StartNewTask('Doing 2 things',2)
SetProgress('Done 1 now',1)
StartNewTask('Big Subtask',40)
...
SetProgress('Done some subtasks',10)
Now, there are 2 progress bars shown, the second at 25% (10/40) and the first at 62.5% (1/2 + 10/40*2)
Like I said above, if you've got >2 tasks in the stack, I only show the first and last (first gives overall progress and never goes backwards, second gives indication of current activity)
You could extend this by giving a weighting to each subtask, i.e.
StartNewTask(Caption,[ListOfSubTaskWeightings])
To make the top progress bar smoother.
Additionally, developers can show all progress bars to see why it takes ages, and I think you could make decent logs out of it.