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
Related
With Cumulative Layout Shift (CLS) now a criteria of Page Speed Insights (PSI) and Google Search Console (GSC) I was wondering what method should be used in order to identify CLS if PSI returns a 0 value but Field Data returns a high value.
For example I have a page that scores 0 on PSI but gets 0.99 CLS for desktop (0 for mobile) according to Search Console.
Using Developer Tools I tried switching on paint flashing and switched on layout shift regions but still get 0 shift, whereas field data says 0.99.
So how do you identify what is causing a Layout Shift using developer tools?
So as nobody has answered this I will put down what I did, it may not be the best way to do it so bear that in mind!
I opened dev tools and setup a new profile under network speed where the latency was 1000ms and the speed to 50kb/s. (where it says "online" next to "disable cache", click there and go to "Custom > "Add...").
This effectively gives you time to see what is happening on a page as resources load in.
I then went to the "rendering" tab and switched on "Paint Flashing", "Layout Shift Regions" and "Layer borders"
I then just watched the page load with this artificial slow down in place.
It was immediately obvious doing this that I had a side menu loading in via AJAX but when it loaded it was about 1px too wide due to a border on it so it made the whole main section shift to the left a tiny bit.
Impossible to notice with the naked eye but really obvious with the above method. This didn't happen on the automated tests as it was (sort of) a race condition in a browser that depended on load order (using async for scripts as I do other manipulation on the aside) and PSI was consistent.
I hope this helps someone until someone comes up with a better way of identifying the root cause of a Layout Shift.
Update
As pointed out in the comments make sure you test at different screen sizes as well.
At the Developer tools, you can go to Performance > Record (the dot at the top). Then refresh the page by using a hard refresh (shift + refresh). NB: Best to make the developer tools sidebar as small as possible to simulate the correct browser size.
As the Developer tools is recording, you can scroll all the way down and stop the recording once you're at the bottom.
Resize the Developer tools tab, and a timeline will appear. This includes a section 'Web vitals'. At 'Experience', you will find blocks that indicate the Layout shifts.
If you hover over the Layout Shift box, the class will be visible in the webpage. You can even zoom in and hover over the timeline at the top, to see the layout at that specific time (and thus the difference in layout causing the layout shift).
If you click on the Layout Shift box, there's a summary in which you'll be able to see the changes e.g. 'Moved from Location [...], Size: [...x...]'
It takes some resizing between all the tabs in the Performance section, but for me, this is really helpful to find out what classes are causing these shifts! Hope this works for you as well.
Chrome DevTools can give you CLS measure and help you to debug pain-points of your website through:
Lighthouse
Performance panel
Red-tinted "Layout Shift" bar will drill you down into impacted elements
More read: https://web.dev/optimize-cls/
I keep finding a scenario where my code stops on a breakpoint in Chrome's debugger, then when I use another tab like "Console", and go back to "Sources", I have lost the place where the code stopped, and I have to click singles-step to get "back on track", but this skips past the sought after breakpoint. Is there some way to get to where the debugger has stopped?
You can use the call stack portion to go to the current location the debugger is stopped at by clicking the top item in the call stack.
As the original writer couldn't submit an image due to his low reputation and the ongoing rules of the site, i will glady provide one for all of us!
You can click on the breakpoint in the list of breakpoints in the breakpoint panel in Sources and it will take you back there.
You can see a line number below. (eg:Line 152, Column 1).
So give Ctrl+G+line number. eg: Ctrl+G+152. You can see the breakpoint.
Is there an option in ollydbg to find out what pieces of code write to a memory address ? Just like Cheat Engine shows all the assembly instructions that write to a specific address.
"breakpoint --> memory" does not work.
Yes,
With olly open and debugging a certain program, go to View tab>Memory or Alt+M
then, find the memory address (first you have to choose the memory part of the program like .data or .bss) and then click on the address (or addresses selecting multiple with Shift) with the right mouse button and hover to Breakpoint then you'll be able to choose the to break the program when it writes or reads the address
A good thing to do is first find the address on cheatEngine then use the breakpoint on ollydbg.
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.
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.