[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Re: memory view renderings don't update
|
Yes, I have noticed other problems with memory view, including the one you mention. Since you bring it up, I'll go ahead and present a full detailed problem list here with instructions for reproducing them. Consider the following simple application (and never mind my memory leak ;-) ):
#include <stdio.h>
#include <stdint.h>
int main() {
int * ptrs[10] = {0};
for (int i = 1; i < 10; ++i) {
ptrs[i] = new int[i];
if (i>1)
--ptrs[i-1];
printf("ptrs[%d] = 0x%08X", i, reinterpret_cast<uint32_t>(ptrs[i]));
}
return 0;
}
Build this and launch debug session,
set bkpt on printf line, run to bkpt,
add a memory monitor for "ptrs[1]"
1. OK here's the first problem. The monitor is created and on my system has a default rendering of "Hex", however the rendering doesn't display until I switch context to another tab (like, the "New renderings" tab) and then back to the rendering tab. Watching the gdb traces console, one can see that the "data-read-memory" command indeed is not executed when the memory monitor was created, but instead when the focus is switched back and forth.
Create another memory monitor for "ptrs[i]". Repeat context switching until it renders correctly.
Create another memory monitor for ptrs[1]'s absolute address. We can see that problem 1. happens for expressions or absolute addresses.
(I noticed that even though the latter 2 monitors render correctly, they do not send a "data-read-memory" commands. Does this mean that Eclipse/CDT is caching memory and it recognized that it had already acquired those addresses?)
Switch back to the ptrs[i] memory monitor and resume the application until we hit the breakpoint for i = 2.
2. Here's the problem initially reported here. The ptrs[i] monitor does not re-evaluate the _expression_ so it does not update. It still displays the old address. We can see that all of the memory monitors update correctly when we write to the old location. But the point here is that the ptrs[i] memory monitor should be showing a new memory location at this point.
Now terminate and relaunch the debug session.
3. After relaunching a debug session, all memory monitors are still in the memory view but their default renderers are not created. Even after creating a rendering and switching context, none of them send "data-read-memory" commands or display correctly.
Delete all memory monitors.
Open a second memory view.
Add a ptrs[i] memory monitor to one of the views.
4. When you open multiple memory views, and open a memory monitor in one, the memory monitor is added to both. This may or may not be a bug, but seems like strange behavior to me. I could see the argument that what harm does it do to synchronize all monitors within all memory views, since you can select different monitors. If this is not a bug, then there is a bug in the fact that the second memory view doesn't show a default rendering, which is like the behavior in 3.
These are all bugs to me bc every other IDE I've used dynamically
re-evaluates expressions to addresses every time you stop in the debugger, and this works for all views (variables view, expressions view, memory view...), and these are persistent and functional across successive debug (launch) sessions. Just in the last few weeks I've started doing heavy C++ development using Helios and CDT 7, and these problems must be hugely inconvenient for anyone doing c/c++ debugging with CDT. Essentially they mean in the best case we have to click a few extra times to get memory view to work, and in the worst case we have to delete and recreate the memory view expressions (and the latter is frequent bc it's on every debug launch).
Does anyone know if these memory view problems were working in pre-DSF CDT, or have they always been present?
Some of these seem like they could be low hanging fruit, and I hope that someone with knowledge of the memory
view can help diagnose and maybe even provide a patch. I'll wait for feedback before filing a bug(s?).
On Fri, Aug 20, 2010 at 7:49 AM, Marc Khouzam
<marc.khouzam@xxxxxxxxxxxx> wrote:
I see this as well.
The reason is that the _expression_ is translated to an
address when first created; although the
_expression_
is still shown to the user, it is backed by that same
address, permanently.
To me this is a bug, but I'm not very familiar with the
memory part of things, so if someone else wants
to confirm that this behavior is not good, that would be
nice. Tim, if confirmed, can you open a bugzilla?
Thanks
Marc
P.S. Another issue I noticed is that when the debug session
is stopped, and then re-launched, the memory
_expression_ is still shown, but does not work. That is
because we don't re-create the proper context for that
memory _expression_.
I need to amend my earlier statement: the memory window doesn't
update only when I am using an _expression_ whose value changes each time I
break in that function. When I use an absolute address or an _expression_ whose
value never changes, it updates fine. So it's as if the memory view doesn't
re-evaluate expressions each time the application is suspended.
On Thu, Aug 19, 2010 at 3:58 PM, Tim Black
<timblaktu@xxxxxxxxx>
wrote:
When
I add a Memory Monitor and a rendering I can correctly see and modify
memory. If I resume my application, and break back in the same thread, same
function, the Memory Rendering never updates. I can create a new rendering,
and the correct memory is shown, but this is extremely cumbersome. This is a
problem regardless of whether I use an absolute address or an _expression_
that evaluates to an address.
I was not able to find anything about
this issue in the archives or on bugzilla. I am using standard Helios/CDT
with GDB 7.1-1 and GDB-DSF debug launchers. This problem plagues me whenever
I do any memory viewing. Please let me know if there is a fix, a workaround,
or if I should file a bug.
Thanks.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
