Comment 1 Teodor Madan 2010-05-10 06:40:24 EDT

Is it reproducible with CDI/DSF gdb? Note, debugger backend should throw an error for calls to IMemoryBlockRetrievalExtension.getExtendedMemoryBlock(String, Object)

With CDT 7.0. I do receive an error pop-up when entering an invalid expression.

Comment 2 Alain Lee 2010-05-10 15:08:18 EDT

(In reply to comment #1)
> Is it reproducible with CDI/DSF gdb? Note, debugger backend should throw an
> error for calls to
> IMemoryBlockRetrievalExtension.getExtendedMemoryBlock(String, Object)
> With CDT 7.0. I do receive an error pop-up when entering an invalid expression.

I investigated this problem further and found and this is what happened. We used our own expression service to evaluate the expression. It knew that the symbol was not defined but did not notify the request monitor that the request failed. Hence, the DataRequestMonitor in DsfMemoryBlockRetrieval.resolveMemoryAddress() handles handleSuccess().
"String value = data.getFormattedValue().substring(2);" actually contains an error message string. Therefore, "drm.setData(new BigInteger(value, 16));" threw an exception and the request was hung forever. We definitely should fix the bug in our expression service. As a safeguard, I think handleSuccess()should also catch exceptions.

Comment 3 Teodor Madan 2010-05-12 09:11:45 EDT

I managed to reproduce this too. On head, the eclipse is hanging when trying to evaluate "main". 

To reproduce:
- Use GDB (DSF) launcher on Windows MinGW with gdb 6.8.
- Open Memory Browser and enter symbol "main"
- UI is locked. 

The details on the symbol "main" from expression view - 

Name : main
	Details:{int (void)} 0x401130 <main>
	Default:{int (void)} 0x401130 <main>
	Decimal:<error reading variable>
	Hex:<error reading variable>
	Binary:<error reading variable>
	Octal:<error reading variable>

Comment 4 Teodor Madan 2010-05-12 09:20:43 EDT

Created attachment 168135 [details]
Bulletproof handleSuccess() from DsfMemoryBlockRetrieval.resolveMemoryAddress()

The patch is just bullet proofing the handleSuccess from  DsfMemoryBlockRetrieval.resolveMemoryAddress(). 

This does not rule-out the fix for GDB-MI expression evaluation service that should fail.

Comment 5 Alain Lee 2010-06-04 10:12:56 EDT

(In reply to comment #4)
> Created an attachment (id=168135) [details]
> Bulletproof handleSuccess() from DsfMemoryBlockRetrieval.resolveMemoryAddress() 
> The patch is just bullet proofing the handleSuccess from 
> DsfMemoryBlockRetrieval.resolveMemoryAddress(). 
> This does not rule-out the fix for GDB-MI expression evaluation service that
> should fail.

Can anyone commit this patch to HEAD?

Comment 6 Teodor Madan 2010-06-07 11:44:21 EDT

Marc, could you please review? 
Taking in account that this bug will hang eclipse UI could we target the fix for CDT 7.0 final?

Comment 7 Doug Schaefer 2010-06-07 11:54:10 EDT

Holding off respin until you guys decide.

Comment 8 Pawel Piech 2010-06-07 14:57:07 EDT

I committed a somewhat more narrow fix.  I'll file a separate bug for DSF-GDB to return a proper error status when expression valuation fails.... though we should hold off on fixing that one as it may uncover issues elsewhere.

Comment 9 CDT Genie 2010-06-07 15:23:09 EDT

*** cdt cvs genie on behalf of ppiech ***
Bug 311564 - [memory] GDB-DSF memory retrieval hangs when creating memory block at function symbol

[*] DsfMemoryBlockRetrieval.java 1.5 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf/org.eclipse.cdt.dsf/src/org/eclipse/cdt/dsf/debug/model/DsfMemoryBlockRetrieval.java?root=Tools_Project&r1=1.4&r2=1.5

Comment 10 Teodor Madan 2010-06-08 02:36:08 EDT

Mark issue as resolved fixed