Community
Participate
Working Groups
Build Identifier: I20100608-0911 The disassembly view sometimes doesn't display all the assembly code it's supposed to when "Show Source" is enabled. I can reproduce the problem by forcing the disassembly view to update: a) if I keep terminating the launch and then relaunching it or b) if I keep toggling the "Show Source" button. I am using a custom DSF debugger plugin that is not gdb/MI based. I'll attach the log generated by my debugger to show the DSF disassembly calls. Reproducible: Sometimes Steps to Reproduce: 1. launch the debug configuration 2. open the disassembly view 3. enable "Show Source" 4. if the disassembly view is not missing any assembly code, keep terminating the launch and relaunching it until you see the bug Another way to reproduce the bug: 1. enable "Show Source" 2. if you don't see the bug, disable "Show Source" and keep toggling "Show Source" until you see bug
Created attachment 177613 [details] Contents of disassembly view and debugger log when assembly code is correctly displayed in disassembly view
Created attachment 177614 [details] Contents of disassembly view and debugger log when assembly code is missing in disassembly view Note that the assembly instructions at addresses ffa01416 to ffa01420 are missing.
I assume those logs were made with the patch for bug 321162 applied? What seems strange is that the first request for disassembly is for a range of 1 byte: Start Address: 0xffa01406 End Address: 0xffa01407 Looking at the code I would assume this is not possible, because retrieveDisassembly makes sure to retrieve a minimum of 32 bytes. Also, the next query for mixed instructions starts again from 0xffa01406. Actually, this should not happen. If the first attempt failed, it should repeat the query for non-mixed instructions. Could you enable disassembly tracing and attach the output when the problem occurs? If you are launch from a workspace, enable the tracing in the launch configuration (org.eclipse.cdt.dsf.ui/debug/disassembly), or put the line org.eclipse.cdt.dsf.ui/debug/disassembly=true into a file ".options" in your eclipse home directory and start Eclipse with -debug.
Created attachment 178435 [details] Contents of disassembly view, debugger log, and trace output when assembly code is missing in disassembly view
(In reply to comment #3) > I assume those logs were made with the patch for bug 321162 applied? Yes. You had already checked in your changes so I just installed the latest nightly CDT build. > What seems strange is that the first request for disassembly is for a range of > 1 byte: > > Start Address: 0xffa01406 End Address: 0xffa01407 > > Looking at the code I would assume this is not possible, because > retrieveDisassembly makes sure to retrieve a minimum of 32 bytes. Sorry, I should have mentioned that the first call to getMixedInstructions() is not coming from the disassembly view but from my debugger plugin, which is using getMixedInstructions() to check if the processor is halted at an address with source code. > Also, the next query for mixed instructions starts again from 0xffa01406. > Actually, this should not happen. If the first attempt failed, it should > repeat the query for non-mixed instructions. > > Could you enable disassembly tracing and attach the output when the problem > occurs? > If you are launch from a workspace, enable the tracing in the launch > configuration (org.eclipse.cdt.dsf.ui/debug/disassembly), or put the line > org.eclipse.cdt.dsf.ui/debug/disassembly=true > into a file ".options" in your eclipse home directory and start Eclipse with > -debug. Ok, I've attached a new log file with the trace output.
From the trace output it looks like some IInstruction objects return an empty string or null for IInstruction.getInstruction(). Can this be true?
Yup, you're right. It turns out that an internal object in my debugger plugin was being destructed early so IInstruction.getInstruction() could have been returning null or an empty string. Thanks for your help!
This is not a bug so I'm closing it.
