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

[Francois Chouinard <fchouinard@xxxxxxxxx>]

Hi Mario,

At first glance, you did find a problem :-)

I will test it further and come back to you soon with either an explanation or a patch.

BR,
/fc

On Wed, Jan 21, 2009 at 5:16 AM, Mario Pierro <Mario.Pierro@xxxxxxx> wrote:

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




_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev