Version: git master (using Devel) OS: Linux Consider code like this: #include <exception> #include <iostream> #include <string> class Test { public: void MyFunction() { std::cout << "Enter" << std::endl; // break point here throw 1; } }; int main( void ) { try { Test t; t.MyFunction(); // break point here } catch (...) { std::cout << "something" << std::endl; } return 0; } If I run it in the KDevelop debugger after issuing 'catch throw' to gdb and with the breakpoints indicated as comments above, the following happens: 1) click Debug 2) debugger brings me to the t.MyFunction(); call 3) click Continue 4) debugger brings me to the std::cout << "Enter" << std::endl; 5) click Continue 6) execution stops, the framestack still indicates it is in MyFunction(), but it is unclear that it is stopping because of the throw. Reproducible: Always Steps to Reproduce: See Details above. Actual Results: Execution stops, but doesn't indicate why or which line. Expected Results: The debugger show highlight the 'throw' line just like it was a normal breakpoint.
Thank you for this detailed bug report. I never debugged c++ code that used exception - so I wonder how plain gdb (from commandline) handles that? Maybe you could provide the backlog of such a debug session.
I've never really used gdb manually. If you tell me how to generate this log, I'll do it :)
See: http://sourceware.org/gdb/current/onlinedocs/gdb/ in your case something like: gdb yourapp break main.cpp:15 run #wait until breakpoint is hit #take a look at the backtrace backtrace continue #exception hit #take a look at the backtrace backtrace
Here you go: (gdb) break Debug.cpp:20 Breakpoint 1 at 0x80489ce: file /media/portable/Examples/c++/src/Exceptions/Debug/Debug.cpp, line 20. (gdb) run Starting program: /home/doriad/build/Examples/c++/src/Exceptions/Debug/Debug Breakpoint 1, main () at /media/portable/Examples/c++/src/Exceptions/Debug/Debug.cpp:20 20 t.MyFunction(); (gdb) backtrace #0 main () at /media/portable/Examples/c++/src/Exceptions/Debug/Debug.cpp:20 (gdb) catch throw Catchpoint 2 (throw) (gdb) continue Continuing. Enter Catchpoint 2 (exception thrown), 0x080488a0 in __cxa_throw@plt () (gdb) backtrace #0 0x080488a0 in __cxa_throw@plt () #1 0x08048ad8 in Test::MyFunction (this=0xbffff0af) at /media/portable/Examples/c++/src/Exceptions/Debug/Debug.cpp:11 #2 0x080489da in main () at /media/portable/Examples/c++/src/Exceptions/Debug/Debug.cpp:20
Ok, I tried your example, but I don't get it. You catch the exception and end your application by return 0 - which is a perfectly normal ending of the application. KDevelop prints "Exited normally". The "catch throw" statement (=Catchpoint) you used in your plain gdb session is not supported by KDevelop - but is that really want you want?
Yes, the 'catch throw' is the thing that will make gdb stop when an exception is thrown. I ran that command manually in the gdb toolview in kdevelop. It indeed stops when it is supposed to, but KDevelop doesn't seem aware of it - it doesn't bring you to the exception line that it stops on.
Ah, now I get it. (Should have read your instructions more carefully) Problem is that the top of the frame stack is somewhere inside libstd, only the second frame is in your application. The same also happens for assertions/crashes inside a lib without debug symbols. I don't know what we could do about this.... Ideas?
Test::MyFunction shows up in the bt when it stops on the 'throw'. I don't know anything about this, but can't you just determine that the first one is not inside the project so go to the second one? I'll let experts answer from here :)
Niko: you could maybe also special-case this, as imo "catch throw" is quite common and if it will always break in libstd, then just check that and do what the user would expect.
Maybe we could even always use the first frame with debug symbols; simply skip all others. This would also fix #125671.
marking as duplicate, it's the same problem *** This bug has been marked as a duplicate of bug 125671 ***