Skip to main content

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



Unfortunately the request flood is still there even after applying the patch to DsfMemoryBlock L


Now the writing to memory issue is fixed both in GDB and our debugger, thanks.


A proposal:


Wouldn’t it be better to have the query.get() calls in DsfMemoryBlock.writeMemoryBlock() and fetchMemoryBlock() fail after a timeout? Or should the timeout happen in the IMemory service implementation, throwing an ExecutionException if needed?






From: dsdp-dd-dev-bounces@xxxxxxxxxxx [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Mario Pierro
Sent: den 22 januari 2009 09:17
To: Device Debugging developer discussions
Subject: RE: [dsdp-dd-dev] DsfMemoryBlock deadlock on memory write?




I am glad that this has been fixed!


There had been a discussion in this mailing list some time ago about our implementation of the IMemory service being flooded with calls when the mouse wheel was used to scroll the Memory View.


The missing done() / thread leak when fetching memory blocks could have been the cause for the slowdown we had…


I’ll try that again with the patched version of DsfMemoryBlock to check if there are any improvements.







From: dsdp-dd-dev-bounces@xxxxxxxxxxx [mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Francois Chouinard
Sent: den 21 januari 2009 20:55
To: Device Debugging developer discussions
Subject: Re: [dsdp-dd-dev] DsfMemoryBlock deadlock on memory write?



You found a problem a little more serious than I thought at first :-)

I opened bug261883 which provides the fix.

Thank you,

On Wed, Jan 21, 2009 at 10:55 AM, Francois Chouinard <fchouinard@xxxxxxxxx> wrote:

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.



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


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?



dsdp-dd-dev mailing list



Back to the top