Review Request: Fix order of handling of command results in GDB plugin.

[Niko Sams]

> On March 10, 2011, 2:39 a.m., Niko Sams wrote:
> > Please try to write a unit test that shows the problem. (might be a bit hard tough)
> > 
> > And there is already a Command Queue in DebugSession, and iirc only one command must be active at a time. I think the problem that should be fixed is that a command is sent before the previous finished. It should be possible to debug this with an unit test.
> 
> Dmitry Risenberg wrote:
>     Writing a unit test would indeed be hard, because this behaviour changes between Debug/RelWithDebInfo versions of the debugged executable.
>     
>     Anyway, investigated this a little more and found out that the following GDB output is causing the trouble:
>     
>     kdevelop(17732)/kdevelop (gdb debugger) GDBDebugger::GDB::execute: SEND: "-exec-step
>     "
>     kdevelop(17732)/kdevelop (gdb debugger) GDBDebugger::GDB::processLine: GDB output:  "*stopped,frame={addr="0x00007fffce079d52",func="content",args=[{name="this",value="0x23f0ef0"},{name="s",value="..."},{name="text",value="\"// Indentation\\n#define foobar(A)\\\\\\n{Foo();Bar();}\\n#define anotherFoo(B)\\\\\\nreturn Bar()\\n\\nnamespace Bar\\n{\\nclass Foo\\n{public:\\nFoo();\\nvirtual ~Foo();\\n};\\nswitch (foo)\\n{\\ncase 1:\\na+=1;\\nbreak;\\ncase 2:\\n{\\na += 2;\"..."},{name="mime",value="<value optimized out>"},{name="leftContext",value="\"\""},{name="rightContext",value="\"\""}],file="/data/commando/Development/KDE/kdevelop/formatters/astyle/astyle_plugin.cpp",fullname="/data/commando/Development/KDE/kdevelop/formatters/astyle/astyle_plugin.cpp",line="87"},thread-id="1",stopped-threads="all",core="2""
>     kdevelop(17732)/kdevelop (gdb debugger) GDBDebugger::GDB::execute: SEND: "-thread-info
>     "
>     kdevelop(17732)/kdevelop (gdb debugger) GDBDebugger::GDB::processLine: GDB output:  "^done"
>     
>     I have some doubts whether this is a valid output (absence of "^running" for "-exec-step" and simple "^done" for "-thread-info"). If not, I'll report it to GDB as a bug. Could you clarify that for me?

hmm, looks like the gdb output is swapped? this must be a kdevelop problem, gdb can't know that kdevelop will send -tread-info. The debug output might be just missleading. You really need a unit test to debug this properly.

> Writing a unit test would indeed be hard, because this behaviour changes between Debug/RelWithDebInfo versions of the debugged executable.
It might be possible to force a BUILD_TYPE like this:
SET(CMAKE_BUILD_TYPE Debug CACHE STRING "default to debug" FORCE)
(untested)


- Niko


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/100831/#review1878
-----------------------------------------------------------


On March 10, 2011, 12:15 a.m., Dmitry Risenberg wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/100831/
> -----------------------------------------------------------
> 
> (Updated March 10, 2011, 12:15 a.m.)
> 
> 
> Review request for KDevelop.
> 
> 
> Summary
> -------
> 
> This patch stores the commands sent to GDB via MI in a queue and applies all output to the queue head. When a result record is received, the queue head is popped.
> 
> This fixes a bug: when running GDB debugging sessions in KDevelop, sometimes the "Internal debugger error" message box pops up with "^done" or "^error".
> This happens when multiple commands are submitted to GDB (one of them from text hint for variable, for example), and one of them receives the result intended for another one. Could not reliably reproduce this, but often happens when breaking in AStylePlugin::formatSourceWithStyle and stepping through it. That could also be a reason for hanging of GDB when 'ready_for_next_command' does not get set correctly.
> 
> Btw, I think GDB::processLine might be improved even more, by distinguishing which types of output do need a command and which do not. Also, is 'ready_for_next_command' necessary at all now?
> 
> 
> Diffs
> -----
> 
>   debuggers/gdb/gdb.h d695062cb2a247c4eea62743f8cc1bc8e93851f9 
>   debuggers/gdb/gdb.cpp 02e23faca971f8be7d28ede40e0b471ab2e44a9f 
> 
> Diff: http://git.reviewboard.kde.org/r/100831/diff
> 
> 
> Testing
> -------
> 
> Manually tested scenario that previously often produced the "Internal debugger error" message.
> 
> 
> Thanks,
> 
> Dmitry
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20110311/7658e2e4/attachment.html>