Bugzilla – Full Text Bug Listing
| Summary: | [Memory Browser] view doesn't update contents of memory tabs when debug context changes | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Norman Yee <normankyee> |
| Component: | cdt-memory | Assignee: | cdt-debug-inbox <cdt-debug-inbox> |
| Status: | ASSIGNED --- | QA Contact: | Jonah Graham <jonah> |
| Severity: | normal | ||
| Priority: | P3 | CC: | alvaro.sanchez-leon, cdtdoug, jonah, marc.khouzam, Randy.Rohrbach |
| Version: | 7.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| See Also: | https://git.eclipse.org/r/84701 | ||
| Whiteboard: | |||
| Attachments: | |||
|
Description
Norman Yee
Created attachment 190041 [details]
Patch for the bug fix.
Created attachment 190307 [details]
Updated patch. Fixes a bug in which only the selected memory tab was updated. Now if you have multiple tabs, all tabs are updated.
Randy, do you know if something has changed here? Created attachment 190551 [details]
Updated patch. Fixes bug in which the tab's rendering type wasn't preserved when the tab was updated..
Folks I am using the latest from HEAD and I do not see this behavior. For different debuggees, I see different list of expressions ( this is work I applied from Alain Lee ). But I see the Memory Browser react to the selection changes in what seems appropriate manner, keeping the selected TABS on a per context basis. I looked at the patch and it seems OK in itself. I will apply it to my local space and see if it compiles and seems to work. But I am not seeing the same negative behavior as described before, in this bugzilla. Could someone who does supply a short "Webex" or some other recording of it occuring. Randy Here is what I do: 1- start a app with two threads with GDB (I used 7.2) 2- both threads run code that use a local variable with the same name (say 'i') 3- interrupt execution and select frame of thread 1 where 'i' is visible 4- open memory browser (not memory view) and put '&i' as the address 5- select thread 2 on the frame that has its own 'i' visible => I don't see the memory browser change. If I press Go on the existing tab (with '&i'), then it changes. OK, I see the difference. I am using multiple launches, each with a single core. Not a single launch with Multiple contexts. Randy Created attachment 190701 [details]
Updated patch. It wasn't disposing the renderings and memory blocks properly.
Comment on attachment 190701 [details]
Updated patch. It wasn't disposing the renderings and memory blocks properly.
This patch seems to cause a "Widget is diposed" exception, after I grabbed the latest CDT sources so I'm rolling it back.
New Gerrit change created: https://git.eclipse.org/r/84701 On reviewing this fix and the bug I believe that there is a misunderstanding on my part as to the purpose of this bug. Option 1) Changing debug context shows the wrong contents for the given address. That is the memory contents are wrong. Option 2) The expressions is not reevaluated on changing context, so even though the memory contents are correct, the view is not showing the address of interest anymore. Comment 6 has steps for this option. If the problem you are seeing is Option 1, then the bug is actually not in the Memory Browser, but in the DSF model. The Memory Browser changes the visible tab folder based on the instance of IMemoryBlockRetrieval received by MemoryBrowser.updateTab(IMemoryBlockRetrieval, Object, String[]). Two threads on the same process share the same IMemoryBlockRetrieval, two different processes have their own IMemoryBlockRetrieval. The MemoryBlockRetrievalManager is responsible for creating IMemoryBlockRetrieval for each context requiring its own unique one. The code in MemoryBlockRetrievalManager.eventDispatched(IStartedDMEvent) creates a new IMemoryBlockRetrieval for each IMemoryDMContext that is started in the debug session. Norman, if the problem is Option 1, can you confirm that DMContexts with different memories are getting unique IMemoryDMContexts? If each core has its own DMContext, ensure that the core implements IMemoryDMContext. I have seen a situation (not in CDT code) where multi-cores are modelled in DMCs with a container DMC implementing IMemoryDMContext and the container contains the individual core's contexts. That would lead to this problem. If the desire is to fix Option 2, then the current fix in https://git.eclipse.org/r/#/c/84701/2 fixes both of these cases by fully reevaluating the memory contents by repopulating everything. However, this comes at significant expense as "walking" the stack becomes very slow instead of nearly instantaneous. This is because each click on a stack frame is a change in DMContext. As a result a better solution for this is needed. Thanks, Jonah Jonah is right. If we consider option 1, the IMemoryDMContext is associated to a process (GDBContainerDMC_7_4) because in our model all threads share the same memory. So if the cores mentioned in this bug are modelled as threads, then the memory browser will not change when selecting a different core-thread. Alvaro had worked on a patch to optionally move the IMemoryDMContext to the thread level for the case of cores. As for option 2 (which was me confusing the original issue), when we deal with expressions, we evaluate them to an address and then keep that exact address as the memory shown. This even happens after you restart eclipse. I've never really like that but to fix it we need to address this root problem is pretty much forgetting that we are dealing with an expression. My guess is that Norman's problem is option 1. Alvaro, do you know what happened to the patch that moves the IMemoryDMC to the threads? Thanks Jonah and Marc for feedback! In our debug model, cores are modeled as threads and each core can have multiple memory spaces with each memory space having its own memory DM context. From what Marc was saying, this would explain why we're not seeing the memory contents update when we click on a different core. Jonah> Norman, if the problem is Option 1, can you confirm that DMContexts with different memories are getting unique IMemoryDMContexts? If each core has its own DMContext, ensure that the core implements IMemoryDMContext. Yes, each memory space has its own unique IMemoryDMContext but our cores can't implement IMemoryDMContext because each core contains multiple memory spaces. Marc> Alvaro had worked on a patch to optionally move the IMemoryDMContext to the thread level for the case of cores. Would Alvaro's patch fix the problem we're seeing? (In reply to Norman Yee from comment #13) > Thanks Jonah and Marc for feedback! > > In our debug model, cores are modeled as threads and each core can have > multiple memory spaces with each memory space having its own memory DM > context. From what Marc was saying, this would explain why we're not seeing > the memory contents update when we click on a different core. > > Jonah> Norman, if the problem is Option 1, can you confirm that DMContexts > with different memories are getting unique IMemoryDMContexts? If each core > has its own DMContext, ensure that the core implements IMemoryDMContext. > > Yes, each memory space has its own unique IMemoryDMContext but our cores > can't implement IMemoryDMContext because each core contains multiple memory > spaces. > > Marc> Alvaro had worked on a patch to optionally move the IMemoryDMContext > to the thread level for the case of cores. > > Would Alvaro's patch fix the problem we're seeing? I have an internal implementation similar to the one mentioned by Norman in the sense that each core is modeled as a thread, then there are multiple memory spaces that apply to each core, so far it seems similar... However this internal implementation allows you to either switch the IMemoryDMContext to the thread level or to the process level, this is not currently a perfect solution as we may also have shared memory spaces between the cores.. The solution still works but you have the inconvenience to treat shared memory spaces as local causing it to not remember monitors, current location, etc.. I had started looking into a different solution where we can allow IMemoryDMContext to be assigned to the thread level or process level depending on the memory space, I unfortunately have not had the change to go back to this effort but it would be great to know if this model would fit other targets. From conversation on cdt-dev[1] I said: Alvaro, would you be able to open source the code mentioned [1]? Perhaps if it was open sourced Andrew and Norman could adapt it for general purpose and contribute that back to CDT? [1] http://dev.eclipse.org/mhonarc/lists/cdt-dev/msg31935.html |