Decompiler runs indefinitely / runs out of memory when a structure field is updated.

[DualTachyon]

Describe the bug The decompiler never ends / gobbles up all the memory when a certain structure field is updated.

To Reproduce 1) Import the .gzf, double click it, click "No" when Ghidra asks to analyse the database. 2) Go to the function "CCard_GetInstance"

No decompilation is observed and the progress bar is running indefinitely, because the field was added before saving.

3) Go to the structure "CCardInfo_t", and clear "CObject_79bccf90" at offset 0x18.

Now the decompilation works right away, once the field is cleared.

I've seen decompiler.exe grow over 10GB of RAM and gave up waiting for it to fill up my 32GB as it takes quite a while.

Expected behavior Decompilation should not run indefinitely.

Screenshots

Attachments I would prefer if the Ghidra database was not shared publicly. Please let me know how I can supply this to you (email, some shared folder, etc).

Environment (please complete the following information):

• OS: Windows 10 and 11, each with latest updates
• Java Version: openjdk version "21.0.4" 2024-07-16 LTS
• Ghidra Version: Public release 11.2.1, but it also happens with the latest master branch (grabbed @ commit ac58d20693c7d6e9b015d9e20b592bb2c02efba7)
• Ghidra Origin: Both official GitHub distro and locally built.

Additional context

[DualTachyon]

There is another function that also "never ends" in the decompiler, it is labelled "big_deinit_function". For this new one, I don't know which structure might be affecting it.

[DualTachyon]

There is another function that also "never ends" in the decompiler, it is labelled "big_deinit_function". For this new one, I don't know which structure might be affecting it.

I fixed this one by correcting some type in a child function... So I suspect the problem in my original post is similar. Fixing a type would get rid of the infinite loop.