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

Bug 337452

Summary: [memory][non-stop] Wrong memory shown for non-stop multi-threaded programs
Product: [Tools] CDT Reporter: Marc Khouzam <marc.khouzam>
Component: cdt-debug-dsf-gdbAssignee: Marc Khouzam <marc.khouzam>
Status: RESOLVED FIXED QA Contact: Marc Khouzam <marc.khouzam>
Severity: normal    
Priority: P3 CC: cdtdoug, pawel.1.piech
Version: 8.0Flags: marc.khouzam: review? (pawel.1.piech)
Target Milestone: 8.0   
Hardware: PC   
OS: Linux   
Whiteboard:
Attachments:
Description Flags
Clearing the cache for the memory context not the execution context marc.khouzam: iplog-

Description Marc Khouzam CLA 2011-02-17 10:26:14 EST 
If you have a program with more than one thread and run it in non-stop mode, the CommandCache in MIMemory does not get properly cleared, and old memory is shown.

1- Run your program and stop the *second* thread (not the first one).  
2- Show a memory while that second thread is selected.
3- Step the second thread
4- The memory is fetched from the command cache, even though the program has stepped.

The reason is that the MIMemory command cache is cleared based on the resumed and/or stopped event which in this case is for a single thread (thread 2).  On the other hand, GDBMemory_7_0#readMemoryBlock() arbitrarily chooses the first thread of the program for all memory requests.  Therefore, the memory is requested for thread 1 but we cleared the cache for thread 2, so we get a stale value.

I have to look into why readMemoryBlock() uses a thread and not a container to request memory...
Comment 1 Marc Khouzam CLA 2011-02-17 15:22:08 EST 
Created attachment 189225 [details]
Clearing the cache for the memory context not the execution context

(In reply to comment #0)
> I have to look into why readMemoryBlock() uses a thread and not a container to
> request memory...

readMemoryBlock() uses a thread for two reasons:
1- it is the only way to tell GDB to select a particular process (before GDB 7.2, there was no way to select a process explicitly, except by selecting a thread within that process)
2- in non-stop mode, some threads may be running and GDB cannot read memory when the current thread is running.  Therefore we must select a stopped thread first. See Bug 337460.

The bug here is that we clear the CommandCache using the dmc that was resumed or suspended.  In all-stop that is ok because the dmc is a container which is the same thing as a memory context, and will clear everything for that memory context.  In non-stop however, the resumed or suspended dmc is an execution context (thread); in that case, we do not want to only clear the memory command cache for that thread, since any thread can modify any memory; therefore, as soon as a thread runs, we must still clear the entire memory cache.

This patch does exactly that.
Comment 2 CDT Genie CLA 2011-02-17 20:23:03 EST 
*** cdt cvs genie on behalf of mkhouzam ***
Bug 337452: Wrong memory shown for non-stop multi-threaded programs.  Cache was not being cleared properly.

[*] MIMemory.java 1.7 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/MIMemory.java?root=Tools_Project&r1=1.6&r2=1.7
Comment 3 Marc Khouzam CLA 2011-02-17 20:31:39 EST 
Committed to HEAD and 7_0.  I realize I missed CDT 7.0.2 but I still want the fix the branch for my own use.

Pawel can you review this small fix?
Comment 4 CDT Genie CLA 2011-02-17 21:23:03 EST 
*** cdt cvs genie on behalf of mkhouzam ***
Bug 337452 -Wrong memory shown for non-stop multi-threaded programs.  Cached was not being cleared properly

[*] MIMemory.java 1.5.2.1 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/MIMemory.java?root=Tools_Project&r1=1.5&r2=1.5.2.1