Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] strange issue with GDB MI interface with pretty prints

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

 

Attachment: out2
Description: out2

Attachment: out1
Description: out1


Back to the top