LLDB memory read failed for 0x0. Is this a bug?

Question

In my LLDB session, memory read 0x00000003 throws an error message.

IMHO, the message error: memory read failed for 0x0 should end with 0x3 .

In case this is no bug but intended behaviour, could anybody explain where the offset/trim comes from?

Further details: x86_64

Answer 1

内存地址将被舍入（向下取整）到最接近的 256 (0x100) 倍数。

Answer 2

如果我没记错的话$eax被定义为0x0 ，所以它说memory read无法读取0x0内的值。

Answer 3

You don't say what system you are on, but it is very common for 64 bit systems to unmap the first 32 bit page of memory. That was originally done to catch 32 bit -> 64 bit transition errors. A common error in 32 bit code was to pass a pointer somewhere as a 32 bit integer, which in a 64 bit world would truncate it to 32 bits. Making the read/write of a < 32 bit pointer always fail makes it much easier to trap this error.

It's also generally handy to map out the pages at 0x0 to catch an access off a nullptr immediately, so many systems map out some pages above zero, even if not the full 32 bits, for that reason as well.

So most likely lldb is right, the memory at 0x0 and some region above that is not mapped, and we can't read it.

Semnodime is right about why the access is 0x0. lldb uses a "memory cache" internally. If you read one bit of memory you're very likely to read some around it, so this speeds lldb up, particularly when doing remote debugging. So by default lldb reads some amount around the address it actually needs.

You can control the amount it reads if you want, using:

settings set target.process.memory-cache-line-size <SomeValue>

And:

settings set target.process.disable-memory-cache true

turns the cache off altogether. If you did that, lldb would then try to read starting with 0x3, but I'm guessing that's still going to fail.