Version: 4.2.81 (using KDE 4.8.0) OS: Linux Today I upgraded to Qt 4.8 (with apt-get, standard ubuntu installation with backports enabled). Since then KDevelop doesn't halt at the specified breakpoints. The application was started through gdb (it is slow as usual when debugging) but it runs over all breakpoints. I can confirm this on two different machines - same Ubuntu setup (standard)... Can you confirm this anyhow? Reproducible: Always Steps to Reproduce: Set a breakpoint in some cpp-file. Start the binary with F9 (debugging). Actual Results: Normal running of the app without halting. Expected Results: It should halt at the breakpoint. It doesn't even work in main.cpp.
are you sure you compile your app in debug mode? debugging in release mode will not work since without debug symbols, it doesn't know where to place break points. please verify this, e.g. by running your app from the cli in gdb: gdb yourapp break main run -> if that doesn't stop either, you did not compile with debug symbols
I always compile it with KDevelops F8. And I also testen in the shell. Shell gdb works perfectly. It just doesn't connect to kdevelop somehow when I start the app with F9. I also can remember that the ladybugs aside the source code turend to red dots when debugging is started. They do remain lady bugs since today. I had this problem now in many releases but after some updates it always started to work again although I didn't change anything. I also deleted all kdevelop files in ~/.kde/share but this didn't resulted in success to me ;-( I guess it has to do something with my last "apt-get upgrade" but can't figure out what... Are there any other ways to investigate the problem more further?
plase activate gdb output in kdebugdialog and post the output you get.
I started kdebugdialog and gdb was checked already. But there is no output in this little application. Who should give me the output? KDevelop or the KDebugDialog-application?
kdevelop
Created attachment 69232 [details] Debug output from KDevelop an its (not working) gdb breakpoints Okay thanks. Now I got the clue :) I enabled gdb-debugging-output. I hope I extracted the correct lines in my attachment. I put a breakpoint in the file myapplication.cpp at line 93. This is the main application and I put the breakpoint at the first line of the constructor. Line 93 is also mentioned in the debug output but I am not familiar with the gdb outputs. Maybe you can find something why KDevelop just runs through the breakpoint an shows the main window on my desktop. Thanks, Andreas
Gdb returns that error: kdevelop(2192)/kdevelop (gdb debugger) GDBDebugger::GDB::execute: SEND: "-break-insert -f "\"/home/pietz/devel/svn/myapplication/src/myapplication/application/myapplication.cpp\":93" " kdevelop(2192)/kdevelop (gdb debugger) GDBDebugger::GDB::processLine: GDB output: "(gdb) " kdevelop(2192)/kdevelop (gdb debugger) GDBDebugger::GDB::processLine: GDB output: "&"No source file named /home/pietz/devel/svn/myapplication/src/myapplication/application/myapplication.cpp.\n"" Can you post the output of a plain gdb (cli) debug session?
Sorry for a stupid question but I am not so familiar with KDevelop <-> gdb. Do I have to set the breakpoint again in gdb cli or should the breakpoint already be set in gdb when I put the breakpoint in KDeevelop in advance and then start gdb from cli afterwards?
with gdb cli I mean gdb alone - without kdevelop. basic example: gdb yourdebuggee break main.cpp:10 run
okay, I tested gdb from cli and in just stop at the right line (e.g. line 93 in the constructor of the main window) and it just stops. KDevelop just opens up the main window if there wasn't set any breakpoint. But I really placed the "lady bug" at exactly the same line in the same cpp-file. Do you have any ideas? I can reproduce this on two different machines since I upgraded to Qt 4.8 with apt-upgrade...
please attach the cli debug session output
this is gdb in cli: $ gdb ./myapplication GNU gdb (Ubuntu/Linaro 7.3-0ubuntu2) 7.3-2011.08 Copyright (C) 2011 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 "x86_64-linux-gnu". For bug reporting instructions, please see: <http://bugs.launchpad.net/gdb-linaro/>... Reading symbols from /home/pietz/devel/svn/myapplication/bin/myapplication...done. (gdb) break myapplication.cpp:93 Breakpoint 1 at 0x44bba6: file application/myapplication.cpp, line 93. (gdb) run Starting program: /home/pietz/devel/svn/myapplication/bin/myapplication [Thread debugging using libthread_db enabled] [New Thread 0x7fffe5e3a700 (LWP 20368)] Breakpoint 1, MyApplication::MyApplication (this=0x1a8bbb0, parent=0x0, fl=...) at application/myapplication.cpp:93 93 setWindowIcon(Ressource::icon(Ressource::IconAbisco)); (gdb) ...thats it and now it waits for input. No main window is displayed. Not very much output, but as expected. Any ideas? Thanks anyways!
Ok, and does it work if you specify an absolute file path? break /home/pietz/devel/svn/myapplication/src/myapplication/application/myapplication.cpp:93
No, this doesn't work. It says: No source file named /home/pietz/devel/svn/myapplication/src/myapplication/application/myapplication.cpp This is strange. This path exists in the shell. What could be the reason for this behavior? Maybe we come close to the bug or miss configuration somehow...
Maybe I have to mention that my project is driven by qmake. It is (IMHO) just a normal simple qmake-pro-file which only contains relative paths in it. I don't use absolute paths because I checkout the repository to different directories sometimes. But something has changed since Qt 4.8 - maybe it is a change in qmake or a change in KDevelop. Before I started my Ubuntu update, debugging worked fine within KDevelop. I assume that KDevelop tells gdb absolute paths, right? This is the only logic solution why debugging doesn't work right now. Can I tell KDevelop to use relative paths within gdb? Or can I change qmake to create my Makefile to use absolute paths within gdb as before?
sounds like a gdb problem. I just did the following test and couldn't reproduce. cat main.cpp #include <QDebug> int main() { qDebug() << "main"; } qmake -project qmake CONFIG+="debug" make gdb main.cpp break /home/niko/qmaketest/main.cpp:4 run qmake --version QMake version 2.01a Using Qt version 4.8.0 in /usr/lib gdb --version GNU gdb (GDB) 7.4
This also works for me with gdb. Strange! What could be the reason why absolute paths don't work with gdb in my project although the path exists in the file system?
try to reproduce the issue by simplifying your application. Maybe it's some qmake option?
I doubt it's a qmake or Makefile problem because the same qmake project works on another machine where no Ubuntu updates were made. Could it really be an ubunutu update problem? On two different machines the same problem?
I experience the same problem on the latest stable ubuntu. Kdevelop doesn't stop at brekpoints. Yes, gdb works well with my executable in the command line, but no integration into Kdevelop. My project is just a "Hello, World" application based on the custom makefile. Version 4.2.3 Using KDE Development Platform 4.7.4 (4.7.4)
Andreas, I would say it's a gdb regression. It should be reported to the gdb bug tracker - though you will need to track down the issue to a simplified testcase that allows the gdb developers to reproduce the issue. Dmitriy, did you try with absolute file path when setting the breakpoint (on gdb cli)?
I doubt it's a gdb issue because gdb didn't change in the update. And this is not the first time debugging is broken in KDE/KDevelop/Kubuntu updates. It happened very often that KDevelop releases have broken debugging functionality. At least Dmitriy Matison can reproduce the problem.
well, you said you can reproduce with plain gdb when using absolute paths. No KDevelop involved. That needs to be fixed first, KDevelop can't do anything about it. (and using relative paths isn't so easy to shouldn't be necessary)
Is it really a gdb issue or can I tell g++ to use absolute paths or not within the Makefile? Maybe qmake produces a stange Makefile?
Ahhhh... :-D I have new information on the issue. I finally got gdb breaking at an absolute file path. It works after I type "list" in the gdb shell. To explain it better, here is exactly what I did: $ gdb ./myapplication (gdb) break /absolute/file/path/to/main.cpp:34 No source file named /absolute/file/path/to/main.cpp. Make breakpoint pending on future shared library load? (y or [n]) n (gdb) list 31 #include "blabla.h" 32 33 int main(int argc, char *argv[]) { 34 QApplication a( argc, argv ); (gdb) break /absolute/file/path/to/main.cpp:34 Breakpoint 1 at 0xC0FFEE: file relative/path/to/main.cpp, line 34. (gdb) run Breakpoint 1, main (argc=1, argv=0x7fffffffe108) at application/main.cpp:34 34 QApplication a( argc, argv ); Isn't that strange? Two times the same command to gdb with different results? What could be the reason for this behavior? I know it seems more like a gdb issue but maybe you have some ideas? By the way: My project has about 1500 source files...
Wow, that is strange. The only idea I have is that you should reduce your code to a basic testcase that still allows to reproduce the issue. And yes, it know that is is quite some work... Other than that you could ask for help on the gdb mailinglist, they are the specialists :D
I posted the issue at the gdb bugzilla but no respnse yet ;-( http://sourceware.org/bugzilla/show_bug.cgi?id=13870 But I have a (maybe) solution for the problem within KDevelop. When I tell gdb in command line: directory /absolute/path/to/my/kdevelop/project then gdb is aware of all files and breakpoints work immediately. Maybe you could tell gdb an additional directory before running the app? I would suggest, to pass it the directory which the user configured in the specific launch-configuration as working directory for the app. Or just the kdev project direcorty? Is it worth a try? Can I test this somehow with parameters in KDevelop?
What do you think about my solution to explicitly add the source-directory of the project? Is someone able to implement this?
...or is there a way to pass additional parameters to gdb within KDevelop? I could then pass "-c /absolute/path/to/my/project" to hopefully enable debugging with KDevelop.
I can also debug my Qt-application with ddd. It works perfectly - so I guess it still has something to do with KDevelop (or its gdb configuration) and not with gdb itself.
This is a gdb bug, as you could reproduce it using plain gdb on cli. It should be fixed upstream. Possible Workaround: create a file containing this directory command and specify that file as "Config gdb script" in launch configuration. KDevelop will source that script before running the application. Maybe it's too early (because the application isn't loaded yet at this point) but it's worth a try.
Again: Debugging my Qt-source with "ddd" works perfectly. How could this be a problem with gdb then? IMHO it is just an issue of KDevelop. Plus, there are a bunch of issues in the internet telling problems with KDevelop and gdb... It would be nice to get some more preference variables in KDevelop to try something out regarding the gdb connectivity.
As I can't reproduce your problem you have to investigate yourself what ddd does different than kdevelop. Do the "bunch of issues" have anything to do with this bug?
I would investigate. But the problem is, that gdb is nearly not configurable at all within KDevelop. Can I pass arguments somehow to gdb within KDevelop to test different parameters? I also tried to setup my ~/.gdbinit and pass some lines like directory /abs/path/to/my/project and this really helped out. KDevelop stopped at breakpoints but really on wrong lines in code. But at least it stopped again. Is ~/.gdbinit the only way to configure gdb? The problem is, that this is a global system setup which works for general gdb and isn't project specific.
see comment 31
I still think it is an issue of KDevelop because the same Qt project works perfectly when I use Qt Creator instead of KDevelop. Debugging in there works just as expected. In KDevelop every breakpoint in my application is mentioned as "dirty" and thus no breakpoint works in KDevelop. Maybe Qt Creator triggers gdb with different arguments?
Hello I just encountered the same problem, after upgrading from Kubntu 11.04 to 12.04. Kdevelop 4.2 used to run with no problem for almost a year. At the beginning, 4.3 seemed to work just fine, but something triggered this problem.
Can nobody tell the difference why QtCreator works fine and KDevelop just doen't stop at breakpoints? Seems like more people have this problem with debugging since Kubuntu 11.04 ....
*** This bug has been confirmed by popular vote. ***
Hm, still seem to be an issue. But I can't reproduce, just tried on Kubuntu 12.04 (with a very basic example, "Simple CMake-base C++ application" Template). So I need help: I need a way to reproduce. - anyone having this issue please create an project using that template and try debugging that (same issue?) - send me a example project where I can see the issue (if the template isn't effected) - post the internal debugger output QtCreator produces (there is a way to activate that in the UI) - so we can find what QtCreator executes and KDevelop doesn't
I suspect the issue is caused by the gdb upgrade, not by the KDevelop upgrade. (and the Kubuntu upgrade did both at the same time)
please give me input on this. Can anyone reproduce and post logs?
I've met similar issue. It happens every time, when I create a project(e.g. from template -> Standard -> Terminal) in a directory with the colon in the path like "~/first : second/my_project". (KDevelop 4.4)
Ilya, that sounds like a unrelated issue if it's about the double colon. Please create a new bug for that.
Kdevelop is still skipping breakpoints, here. By exploring the GDB output, inside the GDB view, here's what append when a breakpoint is being set: (gdb) -break-insert -f "\"/home/gabo/md/flapui_builder/flap_ui/src/widgets/gridparameterswidget.cpp\":54" No source file named /home/gabo/md/flapui_builder/flap_ui/src/widgets/gridparameterswidget.cpp I tried to play with GDB mi2 interface: I run gdb --interpreter=mi2 and triggered the command: -break-insert -f "\"/home/gabo/md/flapui_builder/flap_ui/src/widgets/gridparameterswidget.cpp\":54" the breakpoint is properly set. If I do -environment-cd /home/gabo/md/flapui_builder/flap_ui/bin -break-insert -f "\"/home/gabo/md/flapui_builder/flap_ui/src/widgets/gridparameterswidget.cpp\":54" I get &"No source file named /home/gabo/md/flapui_builder/flap_ui/src/widgets/gridparameterswidget.cpp.\n" Breakpoint has not been set. What is that -environment-cd command for? Is there any workaround to such strange GDB behaviour? Kdevelop 4.4.1 on KDE 4.10.2. gdb 7.5.1. gcc 4.8.0.
Same issue in 4.5 revision, just recompiled from git. When setting a breakpoint from the editor, the breakpoint is properly added to breakpoints view. The full name of the source file where the breakpoint was set is shown. GDB, when program is started in debugging mode, complains about this breakpoint: (gdb) -break-insert -f "\"/home/gabo/md/flapui_builder/flap_ui/src/molexplorer/molviewwrapper.cpp\":732" No source file named /home/gabo/md/flapui_builder/flap_ui/src/molexplorer/molviewwrapper.cpp. Anyway, if I alter the breakpoint source file, in the breakpoint view, replacing the absolute file path with the path relative to the project root, the breakpoint is properly set and hit.
This bug disappeared with kdevelop 4.5 + gdb 7.6. Everything is working like a charm, here!
kdevelop 4.6.0 gdb 7.2-60.el6_4.1 kdevelop breakpoints work sometimes in wrong places. I put BP in my code inside new thread and it stops inside pthread_join.c:pthread_join() which is absolutely wrong place. Btw, that BP from terminal works perfectly well! After removing this BP in kdevelop and adding it again it started to work correctly! This indicates possible memory corruption and may be related to Bug 335534.
Aleksey, I suspect your issue (comment #48) is the same as bug #283379: KDevelop simply fails to pick up the correct thread when the breakpoint is hit. This is a known issue for which we should have a fix soon. Since we never found a reliable reproduction sequence for this rather old bug, and Gabriele reports that the problem disappeared with a gdb upgrade, I'm closing this report.
Had the same problem, got here through a search engine, and found no answer, nor here nor elsewhere, to why kdevelop was ignoring breakpoints. With the suggestion in comment 3, to use kdebugdialog, I have discovered what was going on. The explanation is in this bugreport on gdb's bugzilla: https://sourceware.org/bugzilla/show_bug.cgi?id=17824 The bug, both in kdevelop and gdb, is a lack of documentation on how to setup them to debug an executable when the source files are in another location than the one declared in the symbol table.
Dear Marco, thanks for taking the time to track your particular issue down. From what I understand, this issue is really a problem in GDB, right? As soon as the referenced GDB is fixed, we're good, and in the meantime there isn't really anything KDevelop can do to fix that (at least nothing that is within our limited manpower plus non-existent funding). So I'm leaving this bug closed. If you do feel like KDevelop could/should do something separately from any fix in GDB, please open a _separate_ bug (together with steps for reproduction), since your issue appears different from the originally reported one.
> So I'm leaving this bug closed. Correct. I wanted to put a comment here because this bugreport is number 1 in a search for "kdevelop ignores breakpoint", and the tips I got here about kdebugdialog and the direct testing of gdb/mi were really useful to me. Now here one can also find why, after the original real bug was solved, the same wrong behaviour could still happen, as a consequence of incorrect usage.