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

[Niko Sams]

> On March 24, 2011, 1:04 p.m., Milian Wolff wrote:
> > What happened to this? If the unit test is fixed by the first test, please commit it. Or Niko - any objections?
> > 
> > BTW: the second diff *only* contains the unit test, it should contain both.
> 
> Dmitry Risenberg wrote:
>     This is because my first fix was incorrect, and now I don't know how to fix the bug correctly. May be it's even a GDB bug. I posted the unit test so that people more familiar with GDB can have a look at it.
> 
> Niko Sams wrote:
>     I can take a look, but this will take some time - until I get home beginning of may.
>     So maybe we should leave the review request open.
>     (or, of course - somebody else fixes the problem)
> 
> Milian Wolff wrote:
>     niko, did you look into this / fix it during the sprint?

yes, please close


- Niko


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


On March 20, 2011, 7:58 p.m., Dmitry Risenberg wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/100831/
> -----------------------------------------------------------
> 
> (Updated March 20, 2011, 7:58 p.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/unittests/gdbtest.h e0eccc7 
>   debuggers/gdb/unittests/gdbtest.cpp 5cfc6b1 
> 
> 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/20110625/411a4eb4/attachment.html>