Find on RISC-V registers will make the UI unresponsive and eventually crashes

[AntonKrug]

Description

Find on RISC-V registers will make the UI unresponsive and eventually crashes

Steps to Reproduce

1. Extract fresh copy of 20190101-2023-gnumcueclipse-4.5.1-2018-12-R-win32.win32.x86_64 (tested mainly on 64-bit Windows 10, but can replicate it on 64-bit Debian 9 )
2. Create new fresh workspace
3. New C Project -> SiFive RISC-V Project -> HiFive1 Blinky POSIX semihosting (the project settings might not have impact on it, nor the target, can replicate it with RISC-V 64bit, emualtion, real HW, looks like any RISC-V can have this issue)
4. Build the project and (create corresponding debug launcher) connect to the target and break anywhere (but main is fine).
5. Open Register view, expand the generic registers group them.
   
6. Click on one of them to put them into focus and press CTRL+F for the "Find" feature
7. Watch you CPU and memory to spike.
   

Expected behaviour:
To see the Find dialog:

Actual behaviour:
Get non-responding process, 100% CPU utilization, memory allocation increased, the dialog not showing up and if waited long enough it will crash with "Java heap space" error message. I get lot of "Warn : Got exception 0xffffffff when reading csr3563" warnings (with many CSR numbers, which do not even seem to be fetched sequentially). See the attached log, which was concatenated for brevity, but it kept running and logging out warning very quickly all the time:

reg-ctrl-warn.txt

Sometimes when I manage to terminate quickly the session I will get the dialog (of course now it's no good).

Versions

• 20190101-2023-gnumcueclipse-4.5.1-2018-12-R-win32.win32.x86_64
• Java 8 and tested it with OpenJDK 11
• Windows 10 - 64bit

[ilg-ul]

Does this happen for ARM too?

Does this happen when using the CDT alone (GDB Hardware Debugging)?

I also suggest you monitor the GDB dialog, in the GDB trace console (not visible by default, you need to enable it explicitly).

My guess is that the problem is caused by the huge number of registers used by RISC-V.

[AntonKrug]

No it doesn't happen with ARM, only in RISC-V. The ARM doesn't even need scrolling when the dialog is resized a bit, it might be related to the "need to be resized" that this dialog was never designed to have so much entries to get scrolled through:

My theory is similar that it is possibly present in ARM just the number of registers are in reasonable size where the internal data-structure doesn't fall apart when it contains more entries. Previously the ARM had issue as the target CPUs contained lot of options, so CDT improved the internal data-structure. But the "Register Find" was maybe forgotten and still using some inefficient structure which explodes exponentially. It looks very similar to these:
#307
#313
#325

So it might be similar problem just not fixed on this GUI element (while the others got re-implemented properly).

I didn't test the CDT directly , I expect the native GDB will not have a problem (like ARM does) and it might still contain the issue. So I need to figure out how to prove which module is actually the cause. I might run OpenOCD/emulation by hand, help it a lot and setup things by hand and then see what it does. Or the other idea what I had that I will pinpoint corresponding source code and then it might be clear where the cause of the problem is.

It might be inherited issue from CDT, but CDT might not experience it directly, so even if it's not GME caused issue probably it would be good to keep it here so it's a known limitation.

[AntonKrug]

Just from the curiosity, is MAC affected as well? Could you give it try, the Linux/Windows slightly differ a bit how the UI stops responding, but the gist is the same that the Find dialog is making it haywire. It looks like it doesn't matter as much about the target and project details, just any target with huge amount of registers (so all RISC-V) could cause it.

[ilg-ul]

is MAC affected as well?

yes, selecting the Register tab takes a long time to populate the content, and trying to Find also takes long time to open, but then the selection of the desired register seems ok. the UI is hardly usable if the Registers tab is concerned, but otherwise the debug session seems functional.

I'm afraid you are fighting a lost fight, as long as OpenOCD will list all those thousand registers, debuggers using it will have a hard life to handle them.

[AntonKrug]

It looks like it triggers the edge cases on many tools, it's getting a bit better, but yes it's extreme condition for them.

[ilg-ul]

I'm not sure I can do anything to fix this bug. If you can, please do, otherwise perhaps we should close this ticket.