In the Memory Browser, what is the "Line Offsets" column showing me?

Question

Created Aug ’15

Replies 2

Boosts 0

Views 1.4k

Participants 2

So far I have only been able to find one resource that reference the "Line Offsets"
http://stackoverflow.com/questions/7733019/xcode-memory-addresses-were-in-hex-but-now-are-in-decimal-how-do-i-change-back

The apple documentation for Memory Browser only talks about navigation, and not the views that are up

https://developer.apple.com/library/ios/recipes/xcode_help-debugger/articles/viewing_memory.html

So my question is, what is the "Line Offsets" column on the left of the Memory Browser?
I can't make heads or tails of what those numbers mean

I have also made an SO question:

http://stackoverflow.com/questions/32229414/xcode-memory-browser-what-does-the-left-column-named-line-offsets-tell-me

Does anybody know what these numbers could be?
I am finding one of these "Line Offsets" being referenced by one of my pointers, and it actually causes a bus error, so I'm trying to figure out how this could have happened

Answered by DTS Engineer in 45882022

The column on the left, the one that toggles between hex and decimal when you click it, is the address of the memory being displayed. Consider the following pseudo screen shot.

600000001550  F0290000 01000000 00201E00 00600000  ................
600000001560  80040A00 00600000 00000000 00000000  ................

600000001550 is the address of the byte whose value is F0, 600000001551 is the address of the bytes whose value is 29, and so on.

The reason why you’ve not seen a lot of discussion of this is that:

to folks who are used to assembly-level debugging this is really obvious
folk who are not used to assembly-level debugging rarely look at a raw memory view

I am finding one of these "Line Offsets" being referenced by one of my pointers, and it actually causes a bus error, so I'm trying to figure out how this could have happened

It’s very likely you have some sort of memory management problem. My standard advice for debugging those is:

use ARC (or Swift) everywhere
enable all the compiler warnings and fix anything that it complains about
fix any issues reported by the static analyser
run the app with zombies enabled
run the app with address sanitiser enabled (a new feature in Xcode 7)

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Boost

Answer 1

DTS Engineer OP

Apple

Aug ’15

Accepted Answer

The column on the left, the one that toggles between hex and decimal when you click it, is the address of the memory being displayed. Consider the following pseudo screen shot.

600000001550  F0290000 01000000 00201E00 00600000  ................
600000001560  80040A00 00600000 00000000 00000000  ................

600000001550 is the address of the byte whose value is F0, 600000001551 is the address of the bytes whose value is 29, and so on.

The reason why you’ve not seen a lot of discussion of this is that:

to folks who are used to assembly-level debugging this is really obvious
folk who are not used to assembly-level debugging rarely look at a raw memory view

I am finding one of these "Line Offsets" being referenced by one of my pointers, and it actually causes a bus error, so I'm trying to figure out how this could have happened

It’s very likely you have some sort of memory management problem. My standard advice for debugging those is:

use ARC (or Swift) everywhere
enable all the compiler warnings and fix anything that it complains about
fix any issues reported by the static analyser
run the app with zombies enabled
run the app with address sanitiser enabled (a new feature in Xcode 7)

Share and Enjoy
—
Quinn "The Eskimo!"
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

2

Answer 2

A O OP

Aug ’15

Hey Eskimo

Thanks for the response!
I actually did eventually find out that the "offset" is just the address in decimal, and that you can click to view Hexadecimal -.-

And you're right, this is my first time doing any assembly-level debugging, and actually I found it to be a pretty fun time haha

The reason why I ended up being confused actually was because when I put `po 0x0000600000001234` or whatever address in lldb, it printed the address back in decimal. At first I didn't even realize it was the address in decimal, all I knew is that the number I was seeing looked eerily similar to the number in the "Line Offsets" column in the Memory Browser. So that was silly.

And also for anybody that happens to stumble across this thread,
the issue I was actually having was that I had a non-atomic object that had an occasional race condition that caused the underlying instance variable to be released before it was being read.

This Bus Error actually happened when the property's `isa` was trying to be read, because when it was released, the `isa` pointer was overwritten with 0xbaddc0dedeadbead. Which I later then realized spells out "Badd Code Dead Bead"... but at first I thought it was just gibberish.

Maybe somebody can correct me, but I believe that when an object is released, runtime will set the `isa` pointer to that address to indicate that the object is dead?

Anyways I just had to make the property atomic and that fixed the issue. That was like a week of debugging, too 😟

0