Feature request/suggestion

[440bx]

Hello,

The following applies to Lazarus v3.99 and I believe also to v4.99 but haven't tried that one yet.

When the program being debugged is running, that is not suspended by the debugger, the memory viewer no longer shows what is at whatever address it was told to dump.

The request is that whenever the program is running _and_ the memory address points to committed memory then the viewer should refresh the view after a configurable number of milliseconds have elapsed.  At first blush and under Windows, a simple call to ReadProcessMemory should be enough (IOW, not even necessary to call VirtualQueryEx, which would not be useful anyway because the results of the query may not be valid by the time ReadProcessMemory is called.)

Currently, the absence of this feature, forces using an external memory viewer (such as the one in Process Hacker.)

Comments welcome.

[Martin_fr]

Please add a feature request.

Also, it needs to be tested if all OS allow reading while running.

And, if the debugger backend is gdb/lldb then this only works if the debugged process is internally paused.

[Martin_fr]

Btw ... - while I am aware that this is likely used for something else - ... if you want to know if a specific byte/word/d/qword changed => watchpoints.

[440bx]

Please add a feature request.

Sure

Link: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/41235
Ticket#: 41235

I haven't used the watchpoints yet because I haven't had a bug (yet) that needed that feature.  It's a wonderful feature but, I cannot wish for a situation where I need to use it

[Alexander (Rouse_) Bagel]

There are a few nuances that may complicate the implementation of this feature.
1. What event should be used to update the displayed data? If by the fact of their change, then in Windows to track such a change must be set PAGE_GUARD displayed page, which is not applicable to all addresses. For example, the memory by which KUSER_SHARED_DATA is displayed will not allow to do it. There is a mechanism of HardwareBreakpoint via DR registers, but it is not fully implemented in FpDebug, and it has too small window for tracking (4 addresses up to 8 bytes long in 64 bits per thread), besides it is only for Intel architecture. This leaves only timer-based or separate button-based.
2. Memory validation by calling TDbgProcess.MaskBreakpointsInReadData. This call is not thread-safe and must be executed through TThreadWorker, which can lead to DeadLock when called from the main IDE thread while the debugging thread is running.
3. In Windows, calling ReadProcessMemory from any thread, even the main IDE thread, is really enough to read memory, but in Linux, reading is done via ptrace/process_vm_readv, which require a call from the debuger-thread, which again can lead to DeadLock. So in this case the only way is to read directly from /proc/PID/mem

[440bx]

I would base its implementation strictly on "number of milliseconds elapsed"

[Thaddy]

I would base its implementation strictly on "number of milliseconds elapsed"

That is the 640k question: very rough quantification. I would choose an equally arbitrary nanoseconds elapsed, which is at this moment of writing a better approximation of time elapsed. Or go to picoseconds, but that requires dedicated hardware atm.

[440bx]

I wouldn't try to get fancy.  To ensure a reasonable CPU load, I'd first try 15ms.  This is short enough that it normally feels instantaneous without overly burdening the CPU.