Bug 346827 - The debugger component encountered internal error while processing reply from gdb. Please submit a bug report.
Summary: The debugger component encountered internal error while processing reply from...
Status: RESOLVED FIXED
Alias: None
Product: kdevelop
Classification: Applications
Component: CPP Debugger (show other bugs)
Version: 4.7.1
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: kdevelop-bugs-null
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-04-28 08:54 UTC by Gerhard Gappmeier
Modified: 2015-08-05 19:57 UTC (History)
6 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
signature.asc (180 bytes, application/pgp-signature)
2015-04-28 09:47 UTC, Gerhard Gappmeier
Details
kdev-4.7.1-gdb.patch (607 bytes, patch)
2015-05-01 06:31 UTC, Fernando Rodriguez
Details
Remote debugging example setup with gdbserver on localhost (7.16 KB, application/zip)
2015-07-17 17:43 UTC, Funkster
Details
kdev-4.7.1-gdb.patch (1.77 KB, patch)
2015-08-03 22:45 UTC, Fernando Rodriguez
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gerhard Gappmeier 2015-04-28 08:54:51 UTC
Details:
The exception is: MI type error
The MI response is: ^done,threads=[{id="1",target-id="Thread <main>",frame={level="0",addr="0x00000000",func="_vectors",args=[]},state="stopped"}],current-thread-id="1"

This happens when using a ARM cross-compiler toolchain:
GCC:
arm-none-eabi-gcc (GCC) 4.9.3 20150318 (prerelease)
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

GDB:
GNU gdb (GDB) 7.9
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=arm-none-eabi".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word".

GDB Server:
SEGGER J-Link GDB Server V4.96l Command Line Version

JLinkARM.dll V4.96l (DLL compiled Feb 25 2015 10:11:08)

WARNING: Unknown command line parameter --version found.
-----GDB Server start settings-----
GDBInit file:                  none
GDB Server Listening port:     2331
SWO raw output listening port: 2332
Terminal I/O port:             2333
Accept remote connection:      yes
Generate logfile:              off
Verify download:               off
Init regs on start:            on
Silent mode:                   off
Single run mode:               off
Target connection timeout:     0 ms
------J-Link related settings------
J-Link Host interface:         USB
J-Link script:                 none
J-Link settings file:          none
------Target related settings------
Target device:                 unspecified
Target interface:              JTAG
Target interface speed:        1000kHz
Target endian:                 little

Reproducible: Always

Steps to Reproduce:
1. Configure Debug Launcher
debugger executable=/usr/src/development/gcc-4.9/install/bin/arm-none-eabi-gdb
run gdb script: /path/to/debug_ram

debug_ram:
# Cortex M3 debugging
target remote localhost:2331
monitor speed 1000
# load ELF symbols into debugger
file helloworld.elf
# load ELF to target
load helloworld.elf
monitor SWO EnableTarget 209715200 1000000 1 0
monitor reset
# run to main
set breakpoint pending on
#break main
#continue

2. Select new debug launcher
3. Start debugging

Actual Results:  
message box "The debugger component encountered internal error while processing reply from gdb. Please submit a bug report."

Afterwards debuggin works more or less:
Stepping, Continue and inspecting variables work.

Setting breakpoints from GUI does not work!
Setting breakpoints using GDB cmd prompt works.


Expected Results:  
The debugger should work without issues ;-)

I was already using different toolchains for different targets: ARM, PPC, MSP430.
I never got KDevelop' debugger working with these toolchains.
So these seems to be a more generic problem.

The same toolchains work with cgdb and ddd frontends.
Comment 1 Gerhard Gappmeier 2015-04-28 09:06:00 UTC
Maybe the problem is clear from the description.
If not and you need a toolchain to reproduce the problem I can provide the script I used to build the toolchain.
And it is also possible to reproduce the problem with QEmu without real hardware.
So let me know if you need help to reproduce the issue.
Comment 2 Nicolai Hähnle 2015-04-28 09:23:31 UTC
Hi Gerhard, thank you for the report. I'm interested in support of more "exotic" debug configurations, and have already done work in that direction, but that work has all happened in Git master.

The error you get looks like a typical case of KDevelop not staying properly in sync with GDB's MI protocol. I have fixed many problems like that, but it's unclear whether those fixes will ever be backported.

I would very much appreciate if you could try KDevelop master (based on KF5...) to see if the bug still occurs there.
Comment 3 Gerhard Gappmeier 2015-04-28 09:47:21 UTC
Created attachment 92297 [details]
signature.asc

Hi Nicolai,

do I need both kdeveplatform and kdevelop from master,
or only kdevelop?

On 04/28/2015 11:23 AM, Nicolai Hähnle wrote:
> https://bugs.kde.org/show_bug.cgi?id=346827
>
> Nicolai Hähnle <nhaehnle@gmail.com> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |nhaehnle@gmail.com
>          Resolution|---                         |WAITINGFORINFO
>              Status|UNCONFIRMED                 |NEEDSINFO
>
> --- Comment #2 from Nicolai Hähnle <nhaehnle@gmail.com> ---
> Hi Gerhard, thank you for the report. I'm interested in support of more
> "exotic" debug configurations, and have already done work in that direction,
> but that work has all happened in Git master.
>
> The error you get looks like a typical case of KDevelop not staying properly in
> sync with GDB's MI protocol. I have fixed many problems like that, but it's
> unclear whether those fixes will ever be backported.
>
> I would very much appreciate if you could try KDevelop master (based on KF5...)
> to see if the bug still occurs there.
>
Comment 4 Nicolai Hähnle 2015-04-28 10:18:18 UTC
Yes, you need both, since the debugger component crosses both projects.

I want to be fair and explicitly warn you: Depending on your distribution, you may need even more than that, because kdevplatform/kdevelop master are based on KF5, which some distributions are adopting rather slowly. On Ubuntu 14.10, the list of packages that I installed myself at some point includes: extra-cmake-modules, grantlee, kde-dev-scripts, libkomparediff2, kdevplatform, kdevelop. Obviously it depends on your distribution whether you need all of them.

Still, if you could manage to test that, I would be very happy and promise to do my best to fix all debugger issues you run into :)
Comment 5 Fernando Rodriguez 2015-05-01 06:31:32 UTC
Created attachment 92351 [details]
kdev-4.7.1-gdb.patch
Comment 6 Fernando Rodriguez 2015-05-01 06:38:06 UTC
It seems that this is caused by this commit: http://quickgit.kde.org/?p=kdevelop.git&a=blobdiff&h=ae6b5b864b6e133c6c15b0d8a7ab1e1df6baba47&hp=68e1768e286e06bf69be37bed906e11cb4c144f6&hb=7f5008b07506e6a4b0d817bf7735be4d19da8790&f=debuggers%2Fgdb%2Fgdb.cpp

It assumes that thread-group-started will come as a response to -exec-run (judging by the comment) and it marks the last command as received getting out of sync with gdb. I have a similar setup and it is received when the gdbinit script is loaded.

I uploaded a patch, I just set the replyReceived flag only if the current command is exec-run. I'm not sure if that's the right fix but it works for me. See gentoo bug here: https://bugs.gentoo.org/show_bug.cgi?id=544410
Comment 7 Michael Palimaka 2015-05-04 15:01:45 UTC
Reopening as per investigation/patch in comment #6.
Comment 8 Funkster 2015-07-17 17:43:06 UTC
Created attachment 93628 [details]
Remote debugging example setup with gdbserver on localhost

This is a very basic project that shows the defect, with script to run gdbserver on localhost and another script to connect gdb to it when you hit debug.

as discussed here:
http://comments.gmane.org/gmane.comp.kde.users.kdevelop/8263
Comment 9 Funkster 2015-07-17 18:00:40 UTC
Forgot to mention... the supplied test example requires kdevelop, gdb, gdbserver to be installed, shows the fault with kdevelop 4.7.1 and not with kdevelop 4.7.0. Tested on fedora 20 x64 but the example should compile and run on anything, no special hardware required.

GDB scripts rely on absolute paths, so I have set this example up to be extracted in /tmp
Comment 10 leon pollak 2015-07-18 07:44:05 UTC
Thank you, Funcster!
If I were you, I should set the importance of the bug as critical, is it makes usage of the buggy version impossible - all we 'remote debuggers' downgraded to something working...:-)
Comment 11 Milian Wolff 2015-07-25 15:43:11 UTC
I will look into this the coming days while at akademy. Can you tell me how to set things up? Extract to /tmp, then what? 

1) import project in kdevelop
2) any configuration?
3) run_gdbserver.sh
4) ??
Comment 12 Funkster 2015-07-25 18:50:48 UTC
The project has a launcher set up that runs all the scripts for you, so...

1) import project (the .kdev4 files etc. should be present in the zip)
2) start debugging (what's the default key, F9?)

You should get the MI Type Error popup straight away.

Thanks!
Comment 13 Milian Wolff 2015-07-26 09:09:21 UTC
I just tried it with the KF5 version of KDevelop and don't get any error. I can start debugging, and stop at a breakpoint in main etc. pp. - it all seems to work just fine.

Could you guys try again with the latest and greatest of KDevelop? Maybe this issue is fixed already? Leon, you said you had serious issues with GDB in KF5, could you try to adapt this example with KF5 to reproduce your problems?

Note that I intend to release a first beta of KF5 based KDevelop next week, thus spending time on fixing this in KDE4 is not really high on my priority list.
Comment 14 leon pollak 2015-07-26 09:42:45 UTC
Milian, sorry - what version numbers are KF5? 
I updated to kdevelop 4.7.2 or 1, not remember exactly.
Is it KF5 already?
Comment 15 Milian Wolff 2015-07-26 09:57:34 UTC
Ah, no - that is still KDELibs 4 based. In git master of KDevelop we depend on frameworks 5, and the version for KDevelop there currently is 4.9.90 and will become 5.0.0. If you have the time, it would be cool if you guys could try to compile KDevelop against KF5, for me it looks like it's fixed there. Maybe you could also wait until beta packages for the 5.0.0 release hit your distro of choice, or some other distro which you can install in a VM, if you cannot compile it yourself.
Comment 16 Funkster 2015-07-27 09:43:47 UTC
Hi Milian,

Is the change proposed by Fernando above included in the latest and greatest? If so that would tie up with you not getting the error.

Setting up everything required for compiling the latest is just too much disruption for my main OSes, maybe when the betas are out I could try setting up a VM.

However, I would've thought that getting the fix into a 4.7.2 release would make sense as it will provide a working environment for those who don't always live on the bleeding edge. I'll need to move to fedora 21 at some point soon but can't until there's a working KDevelop in the repos!
Comment 17 leon pollak 2015-07-27 09:51:34 UTC
Voting with both hands here on this side of the Earth...:-)
Comment 18 Gerhard Gappmeier 2015-07-27 09:55:46 UTC
Hiu Funkster,

compiling KF5 is too much trouble, also on my Gentoo.
I used the special Ubuntu iso from here https://techbase.kde.org/Projects/KDevelop4/HowToCompile and installed it in a KVM. This works quick and easy.

Cheers,
Gerhard.
Comment 19 Fernando Rodriguez 2015-07-28 17:07:37 UTC
The code in question has been completely rewritten on git master. The problem only affects version 4.7.1. That's the latest release and what most distros are using so it should be fixed.
Comment 20 leon pollak 2015-07-29 15:07:57 UTC
Hello, Fernando.
Do I understand correctly, that I need to download the 4.7.1 version, apply the patch you provided and then it will work?
or I misunderstood something?
Comment 21 Milian Wolff 2015-07-29 22:51:16 UTC
@Fernando: I completely missed your patch, sorry for that. Please put patches in future up to reviewboard.kde.org - thanks!

@Leon: Yes, please apply his patch and test it, if it works I'll apply it to the 4.7 branch.

Cheers
Comment 22 Fernando Rodriguez 2015-08-02 05:53:55 UTC
@Milian: no problem, will do so next time.
@Leon: That's correct.
Comment 23 leon pollak 2015-08-02 09:05:10 UTC
I applied the patch.
The situation is much better, but still are some problems:
- No MI interface errors are issued any more.
-. Preinserted breakpoints work as expected.

But insertion of a new breakpoint into the running application is ignored.
Also pressing the interrupt button does nothing - application continues to run.

Hope this helps...
Comment 24 Milian Wolff 2015-08-02 14:18:29 UTC
OK, so that means at least that Fernando's patch fixes some issues - I'll push it now then. Regarding the other bugs please open new bug reports and again add explicit instructions on how to reproduce them.
Comment 25 Milian Wolff 2015-08-02 14:21:36 UTC
Git commit 633b49c4bd7e434185c69a3dea1841755b75dcba by Milian Wolff, on behalf of Fernando Rodriguez.
Committed on 02/08/2015 at 14:20.
Pushed by mwolff into branch '4.7'.

Set the replyReceived flag only if the current command is exec-run.

Fixes various MI errors in remote debugging scenarios.

M  +2    -1    debuggers/gdb/gdb.cpp

http://commits.kde.org/kdevelop/633b49c4bd7e434185c69a3dea1841755b75dcba
Comment 26 leon pollak 2015-08-02 14:40:10 UTC
I am not sure this right thing to close this issue.
This bug report has already several descriptions and attachments.
I do not have them.
And I hope Fernando simply needs to take into account this (I suppose this is one) specific case only.
Sorry, if I am not right...
Comment 27 Fernando Rodriguez 2015-08-03 01:52:09 UTC
Leon:

What was the last version where everything worked for you? I've noticed those too but I think they started before the issue that the patch fixes and I have workarounds for them so they didn't bother me enough to look into it, but I will when I get time.

I usually debug a QEMU vm so I just pause QEMU and the debugger breaks, then I can set breakpoints. For debugging an x86 kernel with a gdb stub I issue an int 3 instruction from my code and the debugger breaks (this probably works when debugging through gdbserver as well). For the rare cases when that's not enough I've been using kdbg or gdb directly.
Comment 28 leon pollak 2015-08-03 06:49:09 UTC
My previous version was 4.5.2 - worked fine.
I hope I understand what you  described - but you concentrated in one last problem - not stopping on interrupt button.
The second issue is more important - insertion of a breakpoint while the application is running. Actually this means that you need to set BP before running the application - otherwise it will not be set and, as the interrupt does not work, you have no way to add BP "on the fly".
I suspect that gdb stops the application before inserting a BP into the running code - therefore it does not work...
Comment 29 Funkster 2015-08-03 08:49:16 UTC
4.7.0 allows me to interrupt and to insert breakpoints on the fly using my normal embedded ARM / OpenOCD setup. Leon is correct in assuming that GDB stops the application in order to insert the breakpoint - it's easy to see with OpenOCD as the debug link is slow enough that KDevelop ends up opening whatever file was under the program counter whenever you add or remove a breakpoint while running (which, I might add, is pretty annoying!).
Comment 30 leon pollak 2015-08-03 11:44:16 UTC
I can't install 4.7.0, as it requires different GLIBC version and some more packages...:-(
I do not like to change glibc on my own - too dangerous. And it does not compile for me - compilation errors.
I will be really happy to have 4.7.1 patched with the remaining point of stopping gdb...
Really happy...
Comment 31 Milian Wolff 2015-08-03 12:48:23 UTC
Leon, again - open a new bug report with explicit instructions on how to reproduce your issue with a KDevelop 4.7.1 compiled from latest git 4.7 branch. The initial error discussed in this bug report here _is_ fixed.
Comment 32 leon pollak 2015-08-03 13:03:52 UTC
I got used not to argue with what my wife says...:-)
Report 350916 opened.
Comment 33 Fernando Rodriguez 2015-08-03 22:45:48 UTC
Created attachment 93880 [details]
kdev-4.7.1-gdb.patch

Milian:

Sorry to keep posting here, but they are right. The same commit also breaks interrupt and breakpoints on the fly for most setups. I didn't noticed it because I tested on QEMU and there's an older issue when debugging QEMU. There's also some problems with my last patch:

1. The offending commit was meant for OSX and nobody tested my patch on OSX that I know of.
2. The Interrupt command sends SIGINT to some process. I didn't investigate what PID it's getting but obviously not the intended one so it may kill another process if it has the right permissions.

Since the offending commit is meant for OSX on this patch I just wrapped it in #if defined(Q_OS_MAC). That restore the 4.7.0 behaviour for Linux and it has no effect on OSX. I tested with both QEMU and the gdbserver example. With QEMU interrupt still don't work (but that's another issue) and with gdbserver everything works.
Comment 34 leon pollak 2015-08-05 13:04:56 UTC
Sorry for the delay - a lot of urgent work...:-(
Yes, I applied the last patch - everything works perfect!!!
Fernando!! Thousands of thanks!!!!
Comment 35 Fernando Rodriguez 2015-08-05 19:57:00 UTC
No problem. When you get a chance can you post your result on bug #350916 to see if we can get it committed? This one being closed may not get a reaction.