Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[dsdp-dd-dev] DsfMemoryBlock deadlock on memory write?


I have a question on a possible bug in the DsfMemoryBlock while writing

While debugging our implementation of the IMemory service, I noticed a
strange behavior in the following DSF code:

    private void writeMemoryBlock(final long offset, final byte[] bytes)
throws DebugException {

    	// For the IAddress interface
    	final Addr64 address = new Addr64(fBaseAddress);

        // Use a Query to synchronize the downstream calls  
        Query<MemoryByte[]> query = new Query<MemoryByte[]>() {
			protected void execute(final
DataRequestMonitor<MemoryByte[]> drm) {
			    IMemory memoryService = (IMemory)
			    if (memoryService != null) {
			        // Go for it
		    	  	      fContext, address, offset,
fWordSize, bytes.length, bytes,
RequestMonitor(fRetrieval.getExecutor(), null));
                      // ----> Should a drm.done() call be performed


        try {
        } catch (InterruptedException e) {

It looks like the "drm" data request monitor is never marked as done.
This results for us in a bug when memory is written using the
Traditional memory rendering, which locks the main thread in the
query.get() even after memory has been successfully written. The same
bug happens to me when using the Traditional memory view in the GDB
reference implementation, while the other memory renderings work

I am using DSF sources from v1_0_0-RC4, but I was not able to see any
difference in the HEAD version of DsfMemoryBlock class, and I did not
find related bugs posted.

Am I missing something?



Back to the top