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

Backtrace on "Watch (Read &) Write Access" #43

Open
Sapd opened this issue Aug 19, 2017 · 3 comments
Open

Backtrace on "Watch (Read &) Write Access" #43

Sapd opened this issue Aug 19, 2017 · 3 comments

Comments

@Sapd
Copy link

Sapd commented Aug 19, 2017

Especially when watching strings, you will get access from std::assign. The problem is, that you cannot set a breakpoint on std::assign as it is used very often. Conditional breakpoints e.g. eax == string address are crashing the watched software.

It would be nice if the watch window could show a backtrace, so you know which functions set the string.

@zorgiepoo
Copy link
Owner

The target crashing is likely due to a defect in the debugger not being able to handle a breakpoint being hit simultaneously from different threads very well.. I'm seeing if I can improve this; the debugger code is more complex than I'd like :|.

Getting the stack trace is not easy currently. Generating the stack trace each time a watchpoint was hit is expensive and the code would need to shifted/refactored to do it once per unique address, but I don't think it's worth making that change. More reasonable is a feature request of halting in the debugger for the first watch access, maybe.

A neat workaround is injecting your own bit of code in the debugger. This will lead to much faster execution too. Eg:

cmp eax, 0x2
jne SKIP
nop ; <— SET BREAKPOINT HERE
SKIP:

@Sapd
Copy link
Author

Sapd commented Aug 20, 2017

Thanks for your reply.
I imagined, that for every line in the Watch Window, you would get one backtrace (the first time it appeared).

I tried your injecting approach. But for some reason the target crashes after injecting:
Image

I also tried it at another point which accessed the variable too, there it didn't crash but it also didn't trigger the breakpoint. Could it be because the address in cmp is wrong? I simply used the one the watch window shows "Watching 32-bit write accesses at ADDRESS".

@zorgiepoo
Copy link
Owner

Late response, but because the instruction is:
mov [esi], edi

I'd probably want to compare esi (the memory address) or edi (the new value)
eax is assigned afterwards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants