Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 338968

Summary:

Memory windows do not work across debug sessions, gdb 7.2

Product:

[Tools] CDT

Reporter:

Don Porges <dporges>

Component:

cdt-debug-dsf-gdb

Assignee:

Project Inbox <cdt-debug-dsf-gdb-inbox>

Status:

CLOSED DUPLICATE

QA Contact:

Marc Khouzam <marc.khouzam>

Severity:

normal

Priority:

CC:

cdtdoug, jason.litton, nobody, pawel.1.piech

Version:

8.0

Target Milestone:

---

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
CDT-to-gdb traces for non-working (gdb 7.2) case	none
CDT-to-gdb traces for working (gdb 6.8) case	none

Description Don Porges

2011-03-04 14:18:02 EST

Build Identifier:  I20110127-2034

Eclipse 3.7M5
CDT from cdt-master-8.0.0-I201103040805.zip
DSF, gdb 7.2 -- using 6.8 does not show the bug.  

After creating a memory rendering, killing and restarting the debugger ends up with a memory view full of ???.

Bug 309222 may well be related, as it also applies only to the 7.0 gdb series.



Reproducible: Always

Steps to Reproduce:
Create/build HelloWorld project
Debug; allow it stop at the default breakpoint at start of main
Create a memory monitor at, for instance, &main (the program has no actual variables so this is convenient as a test)
-- memory contents are displayed.
Kill the debug session, restart it; stop at main again.
Go back to the Memory view; user is asked to choose a Rendering for the existing monitor of &main
-- Once it's chosen, the rendering appears, but is filled with ?????.

The Monitor itself can be re-created at this point, and the new instance of it will work fine in this debug session.

Comment 1 Don Porges

2011-03-04 14:19:25 EST

Created attachment 190431 [details]
CDT-to-gdb traces for non-working (gdb 7.2) case

Comment 2 Don Porges

2011-03-04 14:19:58 EST

Created attachment 190432 [details]
CDT-to-gdb traces for working (gdb 6.8) case

Comment 3 Jason Litton

2012-07-02 13:27:14 EDT

I have been chasing this bug in Juno for a little bit now, and I think it's a problem with platform. In the successful scenario, the path travels through org.eclipse.debug.internal.ui.views.memory.RenderingViewPane.memoryBlockRenderingAdded(final IMemoryRendering rendering), which is doing all of the UI rendering here. In CDT, this passes through GDBMemoryBlockRetrieval.getMemoryBlock(vars). In the unsuccessful scenario, the path goes through GDBMemoryBlockRetrieval.createBlocksFromConfiguration(vars). Both of those CDT methods instantiate a new GdbMemoryBlock with the exact same arguments. As far as I can tell, the difference in the scenario is the code path prior to the CDT calls, and so it would seem to be a platform bug. I'm not sure if we want to pass this down to the platform team at this point, or if we can find a way to fix this at the CDT level. I'm willing to code the patches for the second option, but I would need help figuring out the strategy there.

Comment 4 Nobody - feel free to take it

2012-07-02 14:04:32 EDT


*** This bug has been marked as a duplicate of bug 383344 ***