Bugzilla – Full Text Bug Listing
| Summary: | [memory] GDB-DSF memory retrieval hangs when creating memory block at function symbol | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Alain Lee <a-lee> | ||||
| Component: | cdt-memory | Assignee: | Pawel Piech <pawel.1.piech> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Ted Williams <ted> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | cdtdoug, marc.khouzam, pawel.1.piech, teodor.madan | ||||
| Version: | 6.1 | ||||||
| Target Milestone: | 7.0 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Alain Lee
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. (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. 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>
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.
(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? 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? Holding off respin until you guys decide. 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. *** 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 Mark issue as resolved fixed |