Variable rename doesn't work

[croghostrider]

Describe the bug Hi, I have tried to change a variable name in a small binary, but it does not change the name from all equal variables. Its create a new variable declaration, see screen capture. Sorry for my bad English.

To Reproduce Steps to reproduce the behavior:

Expected behavior Change all equal variable names

Attachments main.zip

Environment (please complete the following information):

• OS: Kali 2019.1a (VMware Workstetion Pro on Windows N 10 Pro 64bit)
• Java Version: 11.0.3
• Ghidra Version: 9.0

[emteere]

The renaming of a variable in the decompiler can be problematic at times. If you introduce a variable that the decompiler has at the beginning of it's analysis versus a variable it creates as part of data flow analysis, you can end up with differing variables. The variable merging algorithm can be affected by the initial information of the variable rename.

In your case, I believe the decompiler is correct but not an optimal re-use of the variable. The variable assigned from the ror8 could be considered as another variable in Static Single Assignment.

What happens if you rename uvar2 to be ror8Value?

[croghostrider]

it comes error message "Duplicate name"

[emteere]

Duplicate name was not expected.

Can you post the debug Decompiler .xml file?

[croghostrider]

Yes, where can I find the file?

[alexbrooy]

any news about this issue? I have similair bug: when renaming local var, I don't see it has been renamed. But I get the "duplicate error" when trying to rename again

[acama]

Seems like this bug is still alive in 10.1.2

[antiaim]

Same for 10.1.4

[DCNick3]

I believe one can find the said decompiler XML when clicking this button

Here's decompiler xml (zipped for github) of a function I encountered the bug in

Any attempt to rename or retype puVar1 creates a dynamic (identified by hash rather than an address) local variable (can be seen in the ghidra UI too)

But later when the decompiler is re-run, it seems that the hash does not match what has been previously calculated and so the variable you see in UI stays the same.

Unfortunately, I don't know enough about how the hash is calculated (and how to debug the decompiler...), so I am kind stuck here.

[palmerj]

Any progress on this?

[palmerj]

Note my issue is 16bit MZ DOS EXEs (Real mode).