Hello,
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?
Thanks,
Mario
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?
Hello,
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.
http://dev.eclipse.org/mhonarc/lists/dsdp-dd-dev/msg01568.html
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.
Thanks!
/Mario
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?
Hi,
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.
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
