Skip to content
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

~6 bugs in one short video: Modules, Registers showing bogus output, cannot edit watch expressions, watch expression view rule not respected, assembly view not showing interactable registers, watch address location not correct #337

Closed
seanptmaher opened this issue Oct 18, 2024 · 9 comments
Labels
Bug A report of unintended or broken behavior. Debugger Pertains to the debugger.

Comments

@seanptmaher
Copy link

Debugger version 9.12 ALPHA - Oct 14 2024 [cc2848f] (most recent release on github)

I am debugging a component debug build of Chromium. I can provide you with more info if you'd like.

As the title (which may get clipped) spells out:
~6 bugs in one short video:

  • Modules, where it shows some __elems_ object which is... zero sized types? but which have values?
  • Registers showing bogus output, showing various random objects that Idk what they are.
  • cannot edit watch expressions, screen flashes red, doesn't give any reason why (it's just on the stack?? I can't edit the memory either because...)
  • watch expression view rule not respected, it shows it in hex with the enum name.
  • assembly view not showing interactable registers, only those AFTER $rip
  • watch address location not correct, as shown in my jumping to that address and it containing garbage.

Here is the video in question:

When there is a "bug," I tend to circle my mouse around it :P

https://drive.google.com/file/d/1bcjgRgQ1t_0uvXYzWZEL501NHgCGE3fV/

@ryanfleury
Copy link
Collaborator

ryanfleury commented Oct 18, 2024

Without testing Chromium locally, I believe I've fixed the registers/modules view problems as of 1865c33.

watch expression view rule not respected, it shows it in hex with the enum name.

This should be fixed as of 53c624a.

To try out the above fixes, you can pull the repository, switch to the dev branch, and build locally (you can get a release copy - which I expect will be much desire for Chromium - via build raddbg release). It should be pretty easy to build locally if you haven't already, the instructions are in the repository readme if you need them.

As for the others:

screen flashes red, doesn't give any reason why

The reason is in the bottom right-hand corner of the window, but it likely just says that committing failed. I'll try to recreate that one locally, I have a suspicion of what is causing that.

assembly view not showing interactable registers, only those AFTER $rip

I think this is likely just an assembly syntax lexing problem (it looks like the lexer got confused at some point) - to get around it temporarily, you can select the register name and hover it.

watch address location not correct, as shown in my jumping to that address and it containing garbage.

This is not a bug, as the watch pin "address location" is referring to the spot in disassembly where you've attached that pin, not the evaluated address of the expression. (You can see how that address changes if you drag/drop that pin around). When you navigate to the address of the pin, that address is the location within the disassembly that you've attached that pin to. So when you navigate there and it shows the various byte values, those are the byte values of the machine code, not of the expression you're evaluating.

@ryanfleury
Copy link
Collaborator

Okay, that watch window mutation bug should also be fixed as of b3d6b29. You should be able to write to that value.

You can't modify in the memory view yet, but this is just a known limitation of the memory view; that UI will be more fleshed out a bit later on.

@seanptmaher
Copy link
Author

Thanks for the super fast response!

@seanptmaher
Copy link
Author

In the interest of not creating more issues:

Here's a new video showing stepping being broken when it has to actually step over a function call:

https://drive.google.com/file/d/1EGY2o3tFKJRtaSW8eUXDgVOgz37O2Hbn

Basically, it freezes, "running" the target, but it's actually paused at the correct 'ret' instr.

Then, pausing, and stepping once more will return to the right location.

@seanptmaher
Copy link
Author

Thanks for your work on this by the way, you're doing god's work.....

@seanptmaher
Copy link
Author

If you'd rather I create new issues for these minute little things for easier bugtracking, let me know and I'll do that.

Hovering over a stack frame with extensive template use, the types of the parameters cause the name to be super long, pushing the entire signature out of screen. Can that be changed so it's left-justified and won't go wider than the width of my screen, either wrapping or pushing off to the right?

image

@mistymntncop
Copy link

In the interest of not creating more issues:

Here's a new video showing stepping being broken when it has to actually step over a function call:

https://drive.google.com/file/d/1EGY2o3tFKJRtaSW8eUXDgVOgz37O2Hbn

Basically, it freezes, "running" the target, but it's actually paused at the correct 'ret' instr.

Then, pausing, and stepping once more will return to the right location.

Might be related to this line stepping bug ?
#322

@ryanfleury ryanfleury added Debugger Pertains to the debugger. Bug A report of unintended or broken behavior. labels Oct 21, 2024
@ryanfleury
Copy link
Collaborator

Yeah, I would prefer new issues for each separate category of bug - that helps me keep track of things a bit better.

The disassembly lexing bug has been fixed as of e9666e2. I've also fixed the thread callstack tooltips when extremely long autogenerated symbol names are used; there is still no path for trying to make those names more helpful, but I've just stopped the tooltip from overtaking too much. I've fixed #322, so I'll look into that stepping bug now.

@ryanfleury
Copy link
Collaborator

Actually, that does look like it would've been caused by the #322 bug, which has now been fixed. So I'll close this issue, but let me know if you run into the same bug again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug A report of unintended or broken behavior. Debugger Pertains to the debugger.
Projects
None yet
Development

No branches or pull requests

3 participants