| Re: [cdt-dev] strange issue with GDB MI interface with pretty prints |
|
Often GDB bugs are triggered by the way CDT uses it. What I recommend in cases like this is to try to reproduce the problem in command-line GDB by using the same set of commands used by CDT when you see the crash. To do that easily: 1-
take the ‘gdb traces’ from CDT 2-
edit the file to only keep the commands 3-
start GDB on the command-line to accept MI commands: > gdb –nx –I mi 4-
copy-paste the MI commands into GDB 5-
if you get the crash, you can then gradually remove MI commands that you don’t think matter and try again, until you isolate the reason this is happening. For example you might find out the crash happens because CDT uses -enable-pretty-printing which you didn’t use when you originally tried in the GDB command-line. This will allow you to know if the problem in
in GDB or not. Marc From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Ayupov, Andrey Hello all, I am having a strange issue with my pretty prints that seems to work fine in a standalone GDB but crash GDB when running from Eclipse (Kepler SP1). The crash happens not all the time. The pretty print is for SystemC data type sc_biguint
(source can be found here:
http://www.lysium.de/docs/systemc-2.2/docs/html/classsc__dt_1_1sc__biguint.html ). For this type in my pretty print I would call the “to_string()” method. First of all, it does not crash gdb from Eclipse if a variable is a class member, but would if a variable
of this type is a function local variable or a function argument. Also, it has to do with the fact that I call a method on the variable and would work if I just get some field. Another very peculiar thing is when I set breakpoints in the MI interface code,
and step through it, it will not crash it. So I am very puzzled and not sure where to look. Since in gdb the pretty print works for those cases I described, I thought the problem is in the way Eclipse communicates to GDB. So I added print out in the following
function: Void org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl.processNextQueuedCommand() after the command is fetched, like this:
… final CommandHandle handle = fCommandQueue.remove(0); System.err.println("processNextQueuedCommand: "+ fCommandQueue.size() + " command: " + handle.toString()); //$NON-NLS-1$//$NON-NLS-2$ … The crash happens when locals are printed for a given scope at a breakpoint. I start my C debugger, it will stop and the main function first and then I click continue, and it will crash gdb at the next breakpoint printing what’s in attached
file out1. The gdb trace tail looks as follows: 232,989 48-stack-info-depth --thread 3 11 232,990 48^done,depth="7" 232,990 (gdb) 233,281 49-thread-info 3 233,283 49^done,threads=[{id="3",target-id="Thread 0x7ffff7cdb700 (LWP 35216)",name="loop_restruct_t\ ",frame={level="0",addr="0x00000000004044c9",func="loop_restruct_test::run",args=[{name="this",value\ ="0x8c00c0"}],file="../loop_restruct_test.h",fullname="/mypath/loop_restruct_test/loop_restruct_test.h",line="92"},state="stopped",co\ re="7"}] 233,283 (gdb) 233,517 50-stack-list-locals --thread 3 --frame 0 1 233,524 51-thread-info 1 233,637 ~"frame.c:1985: internal-error: get_frame_pc: Assertion `frame->next != NULL' failed.\nA pro\ blem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debuggin\ g session? " 233,637 ~"(y or n) [answered Y; input not from terminal]\n" 233,637 ~"frame.c:1985: internal-error: get_frame_pc: Assertion `frame->next != NULL' failed.\nA pro\ blem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nCreate a core file\ of GDB? " 233,638 ~"(y or n) [answered Y; input not from terminal]\n" But again, not sure if it is a gdb bug because I can successfully see all the variables in the standalone gdb. When I run the same while debugging Eclipse in Java and having a breakpoint at the line with printout above, it will not crash gdb !! and you can see that some variables were created successfully at the breakpoint as you can see in out2
attached. You can see the order of commands send through MI is different, but not sure if that’s important. If anyone has a clue where to look next. I would much appreciate this.
Thank you, Andrey |