Low-level Error: Overlapping input varnodes

[int3rsys]

Describe the bug
Ghidra is unable to decompile a certain function, part of a x64 elf binary.

Environment (please complete the following information):

• OS: Ubuntu 22.04.3
• Java Version:
• [openjdk 17.0.8.1 [2023-08-24]
  OpenJDK Runtime Environment (build 17.0.8.1+1-Ubuntu-0ubuntu122.04)
  OpenJDK 64-Bit Server VM (build 17.0.8.1+1-Ubuntu-0ubuntu122.04, mixed mode, sharing)
• Ghidra Version: 10.3.2

To reproduce:
decompile attached binary: zabbix_agentd.zip
goto function zbx_tcp_recv_ext

EDIT:
the debug xml file:
zbx_tcp_Recv_ext.zip

[LukeSerne]

I cannot reproduce this in Ghidra 10.4. It is possible that this error is caused by the types of the parameters of the function. Since the default has no parameters by default, Ghidra will guess the types, and the guessed types do not cause this error.

It would be helpful if you could share the debug xml for this function. To generate this file, go to the function that causes the error, click the downwards pointing arrow (as indicated in the screenshot below) for a dropdown menu to appear, and click "Debug Function Decompilation" in that menu. Then choose a location to store the xml, and an xml will be created there that allows others to easily reproduce the same decompiler input. If you could share this xml, that'd help a lot in diagnosing and solving this issue.

[int3rsys]

I cannot reproduce this in Ghidra 10.4. It is possible that this error is caused by the types of the parameters of the function. Since the default has no parameters by default, Ghidra will guess the types, and the guessed types do not cause this error.

It would be helpful if you could share the debug xml for this function. To generate this file, go to the function that causes the error, click the downwards pointing arrow (as indicated in the screenshot below) for a dropdown menu to appear, and click "Debug Function Decompilation" in that menu. Then choose a location to store the xml, and an xml will be created there that allows others to easily reproduce the same decompiler input. If you could share this xml, that'd help a lot in diagnosing and solving this issue.

Sure thing, thanks!
zbx_tcp_Recv_ext.zip

I attached the file to this message and also in the main question

[LukeSerne]

The two varnodes that overlap are XMM1_Qa and XMM1. I'm not sure why these are both detected as inputs. If I lock the existing function prototype before decompiling, there is no error, and the function decompiles successfully. As a workaround, you can try changing the prototype of the function to long zbx_tcp_recv_ext(long, int, byte) - that might help.

I wonder why Ghidra attempts to mark both XMM1 and XMM1_Qa as input and why I can't seem to trigger it in Ghidra 10.4. Perhaps someone more familiar with the internals of the decompiler can help clear that up.