Unwind frame task triggered by a simple variable hover in the debugged target listing is very slow to complete

[mxtsdev]

Running Ghidra built from the master branch on an x86-64 target in Windows and using dbgeng (IN-VM).

A single unwind task in VariableValueHoverService triggered by a variable hover in the static listing takes 10 minutes to complete. If I step into another function, same thing happens again.

I don't know if this is expected behavior or not, but it appears to decompile the entire target each time the unwind task is triggered after you have switch to a new stack frame.

Profiling of a single unwind task using simple CPU instrumentation:

Hundreds of millions of calls from the decompilation:

[mxtsdev]

This might have been better suited as a bug report (issue). It evolved while I was typing up a question about how long one should expect the 'unwind stack' action to take to complete after encountering some odd behavior while debugging.

[d-millar]

Think this is definitely one for @nsadeveloper789. The stack indicates you're unwinding use the PCodeEmulator, and that is definitely not going to be fast. That said, am not sure how if there's another option. Will ping him directly tomorrow if he hasn't responded directly beforehand.

[nsadeveloper789]

This might just be a matter or caching. Whenever the unwinder encounters an indirect call, it defers to the decompiler to divine the signature at the call site. My best guess is the unwinder is asking the decompiler to re-decompile the same (caller) function every time it encounters an indirect call within. We can create an internal ticket, but this feature is not a top priority at the moment.

To answer your question about "how long," it depends on the size of the function. In particular, the unwinder seeks the shortest path (in terms of basic blocks) from entry to the PC, and then from PC to any exit. If that path is long or perilous, then things may go slowly, or not well in general. This rule then applies recursively to each frame unwound. I'd consider any time longer than a few seconds exceptionally poor, so thank you for reporting this.

Can you file an issue, and (by any chance) can you share the target binary and tell us how to replicate this? The caching thing is one hypothesis, but I don't understand why "hundreds of millions of calls" are made to the decompiler to begin with.

[mxtsdev]

Unfortunately, I cannot share the binary as it is proprietary, and I do not have permission to do so.

I have been trying to find ways to reproduce the problem in another binary without success. On one hand, it is disappointing that I cannot reproduce it, but on the other hand, it shows that the whole VariableValueHoverService feature actually works in most situations.

From what I have been able to test, unwinding the stack is normally either quick to complete or times out after a short while. Weirdly, no matter if the task completes, times out, or I manually cancel it, the value I expect to see is, in most cases, shown on the next hover.