Memory view problem on Ubuntu using J-Link plugins

[darnyperez]

Setup

• I'm using Eclipse 4.14 (2019-12) with CDT 9.8 and GNU MCU Eclipse 4.4.2 plugins for Segger J-Link.
• I'm running GDB debug sessions using a Silicon Labs board BRD2204A - EFM32GG11 - ARM Cortex-M4.
• I'm using Segger's JLinkGDBServerCL (v6.70) and GDB client arm-none-eabi-gdb (v10.1.90 from GNU ARM Toolchain).

Behavior on Windows

1. When running a GDB debug session on Windows, I open the Memory view and specify a memory address for device's Flash address space, e.g. 0x0.
2. The Memory view will then load the data for that block of memory starting at the specified address (e.g. 0x0 - 0x1AF).
3. When I scroll to the bottom of the Memory view for the current block, it will automatically load the data for the next block of memory (e.g. 0x1B0 - 0x2AF). This behavior occurs each time the scrollbar reaches the bottom of the Memory view.
4. When the Memory view loads data for a block of memory, I see in the Console view log statements indicating its loading data for each block of memory. Example: Reading 432 bytes @ address 0x00000000

Problematic Behavior on Ubuntu

• When I execute the steps 1-2 above on Ubuntu 20.04, it works the same as on Windows.
• But when I execute step 3 above, the Memory view does not load the data for the next block of memory when the scrollbar reaches the bottom of the view.
• I don't see any error messages in the eclipse log file in the workspace with regard to it not loading data for the next block of memory.
• I looked through the archived discussions and did not see any topics concerning this issue.

Questions

1. Is this an known bug? I did not see it listed at https://eclipse-embed-cdt.github.io/support/known-issues/
2. What debugging steps should I try? Would launching eclipse with -debug <options file> help and if so, which plugins should I enable in the options file?

Thank you!

[ilg-ul]

Hi @darnyperez,

Thank you for the bug report.

Could you test the behaviour of the memory view on the same Ubuntu machine, but with a simple native project (not an embedded project)?

[darnyperez]

Could you test the behaviour of the memory view on the same Ubuntu machine, but with a simple native project (not an embedded project)?

On Ubuntu, I experience the same behavior for a Local C/C++ project (not targeting an embedded device).

[ilg-ul]

In this case the problem is in CDT.

@jonahgraham, could you suggest how to proceed to register a ticket in the CDT bug tracker?

[jonahgraham]

This sounds like it is working by design, but you have different setting on Windows and Linux.

Please check if on Windows you are using "Automatic" for Table Rendering and on Linux "Manual". To see the prefernces, click the "hamburger" menu (or drop-down menu on older Eclipses) on the view and choose "Table Rendering Preferences..." like in this picture:

See the full help in the manual, but the key part is quoted here:

To set preferences for memory renderings that are displayed in a table, click the Memory view down-arrow icon and select Table Renderings Preferences. In the resulting preferences dialog box, there are two options:

Automatic radio button: Select this if you want the debugger to automatically preload a buffer of memory before and after the visible region in the Memory view. When you select this setting, you can easily scroll away from the visible region of memory with scroll and page up/down actions.
If the buffer size is large, the performance of refreshing the Memory view can be negatively impacted (the Memory view refreshes when there is a potential for memory change - so, for example, the Memory view refreshes when you step, suspend after running, change a variable or register, or modify memory). This is because a request for more memory must be made from the debug engine for each refresh. On the other hand, if the buffer size is too small, the performance of scrolling can be negatively impacted. This is because a request for more memory must be made from the debug engine when the buffer is exhausted. Given this performance trade-off, you need to set this option to suit your needs.

Manual radio button: If you select this setting, then the number of lines per page that you specify will be loaded into the Renderings pane. When using this setting, you have more control in choosing exactly what you want to monitor, however, you will not be able to scroll outside the buffer defined by this page size setting. Instead, to view memory from the next page or previous page, you must right-click to use the Previous Page and Next Page actions from the pop-up menu.
If the buffer size is large, the performance of refreshing the Memory view can be negatively impacted (the Memory view refreshes when there is a potential for memory change - so, for example, the Memory view refreshes when you step, suspend after running, change a variable or register, or modify memory). This is because a request for more memory must be made from the debug engine for each refresh.

[darnyperez]

• Thank you for the quick help and detailed answer, @jonahgraham and @ilg-ul !
• I've confirmed that Windows has the preference set to Automatic by default and Linux has the preference set to Manual by default.
• On Linux, I'm able to automatically load multiple blocks of memory by scrolling after updating the preference to Automatic in the Table Rendering Preference page.

[jonahgraham]

Thank you for bringing this to my attention - I think it is a mistake that the default is different on different platforms. It should probably always default to Automatic. I have raised Bug 579212 to try to resolve that part of the issue.

[jonahgraham]

Not a mistake - but a workaround for a bug, so I have closed bug I just raised. See Bug 579212 for more details.

[ilg-ul]

Does this old GTK bug still affect Eclipse?

@darnyperez, if you change this setting to Automatic on your Ubuntu 20, does it work as expected?

[jonahgraham]

This bug still does affect Eclipse. If you randomly scroll up/down in the memory view on Ubuntu after a short while it stops updating. According to the bug from 2004 / 2005 it is a README entry, but I couldn't track down where. Maybe once upon a time the [README] tag in bugzilla was meant as the readme for the project?