New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Disassembly view accesses garbage beyond visible region #588

Open
10110111 opened this Issue Aug 12, 2017 · 4 comments

Comments

Projects
None yet
3 participants
@10110111
Contributor

10110111 commented Aug 12, 2017

To reproduce, to to the end of current region, and at the address 0x...fe put bytes 00 90. You'll get add [eax+imm32], reg8 instruction, where imm32 is garbage not actually present in debuggee's address space.

@10110111

This comment has been minimized.

Show comment
Hide comment
@10110111

10110111 Aug 12, 2017

Contributor

It appears to be not a bug, at least the data are not garbage: in my test program, after the region [0x8048000,0x8049000) there is another region, [0x8049000,0x804a000), from which the bytes are successfully read by the disassembly view. I'm not sure though that this is good behavior of QDisassemblyView: it makes it look as if there's no bytes after a region, but in reality there's an accessible adjacent region.

Contributor

10110111 commented Aug 12, 2017

It appears to be not a bug, at least the data are not garbage: in my test program, after the region [0x8048000,0x8049000) there is another region, [0x8049000,0x804a000), from which the bytes are successfully read by the disassembly view. I'm not sure though that this is good behavior of QDisassemblyView: it makes it look as if there's no bytes after a region, but in reality there's an accessible adjacent region.

@eteran

This comment has been minimized.

Show comment
Hide comment
@eteran

eteran Aug 14, 2017

Owner

Right, I have noticed this before. I'm not 100% sure what the best policy is to handle this. I can imagine some code which attempts to be unfriendly to debuggers by having some code straddle regions or something to that effect. Maybe we can color the bytes that are from an adjacent region differently so they stand out as "not from here"? I dunno, just throwing out random thoughts.

Owner

eteran commented Aug 14, 2017

Right, I have noticed this before. I'm not 100% sure what the best policy is to handle this. I can imagine some code which attempts to be unfriendly to debuggers by having some code straddle regions or something to that effect. Maybe we can color the bytes that are from an adjacent region differently so they stand out as "not from here"? I dunno, just throwing out random thoughts.

@AaronOpfer

This comment has been minimized.

Show comment
Hide comment
@AaronOpfer

AaronOpfer Aug 14, 2017

Contributor
Contributor

AaronOpfer commented Aug 14, 2017

@10110111

This comment has been minimized.

Show comment
Hide comment
@10110111

10110111 Aug 14, 2017

Contributor

I'm guessing that if there is no adjacent region, we'd show uninitialized memory from the read buffer
instead.

Not really: I've actually tried to debug it before commenting on this issue. Actual code just relies on being able to read data from the process, and if it succeeds, it doesn't check whether it has just read past the end of the block given to it. The memory is fully initialized, just belongs to a different (albeit adjacent) block of debuggee's address space.

Also, I seem to remember seeing this bug reported before. Did it come back to life, or did we never fix it?

No, the one which has been fixed remains fixed, we don't show true garbage now.

Contributor

10110111 commented Aug 14, 2017

I'm guessing that if there is no adjacent region, we'd show uninitialized memory from the read buffer
instead.

Not really: I've actually tried to debug it before commenting on this issue. Actual code just relies on being able to read data from the process, and if it succeeds, it doesn't check whether it has just read past the end of the block given to it. The memory is fully initialized, just belongs to a different (albeit adjacent) block of debuggee's address space.

Also, I seem to remember seeing this bug reported before. Did it come back to life, or did we never fix it?

No, the one which has been fixed remains fixed, we don't show true garbage now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment