[dsdp-dd-dev] DsfMemoryBlock deadlock on memory write?

["Mario Pierro" <Mario.Pierro@xxxxxxx>]

Hello,

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

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[]>() {
			@Override
			protected void execute(final
DataRequestMonitor<MemoryByte[]> drm) {
			    IMemory memoryService = (IMemory)
fRetrieval.getServiceTracker().getService();
			    if (memoryService != null) {
			        // Go for it
	    	              memoryService.setMemory(
		    	  	      fContext, address, offset,
fWordSize, bytes.length, bytes,
		    	  	      new
RequestMonitor(fRetrieval.getExecutor(), null));
			    }
                      // ----> Should a drm.done() call be performed
here?				
			}

        };
        fRetrieval.getExecutor().execute(query);

        try {
            query.get();
        } 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
correctly.

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?

Thanks,

Mario