Summary: | GDB crashes when creating catchpoint | ||
---|---|---|---|
Product: | [Applications] kdevelop | Reporter: | Alex Richardson <arichardson.kde> |
Component: | CPP Debugger | Assignee: | kdevelop-bugs-null |
Status: | RESOLVED UPSTREAM | ||
Severity: | major | CC: | arjan, chaofeng111, ischdoepperdodrausse, niko.sams |
Priority: | NOR | ||
Version: | git master | ||
Target Milestone: | 4.3.0 | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
Alex Richardson
2013-03-13 10:56:32 UTC
if you try doing exactly the same with gdb on the commandline (including --interpreter=-mi2), does it also not crash? Interesting, when I run it using interpreter==-mi2 I get the following if the program is already running: (gdb) catch throw &"catch throw\n" ~"Catchpoint 7 (throw)\n" Abgebrochen (Speicherabzug geschrieben) If the process is not running yet I get the following: (gdb) catch throw &"catch throw\n" ~"Catchpoint 5 (throw)\n" =breakpoint-created,bkpt={number="5",type="breakpoint",disp="keep",enabled="y",addr="0x000000000050e200",what="exception throw",times="0",original-location="__cxa_throw"} ^done (gdb) However then it aborts before hitting main. Seems like it is an upstream bug, although I could swear it has worked before. I have this same bug (using Eclipse) only when having forked the process and the breakpoint is set on the child as well and only when I have added C++ object (cpp-file) added to the C project. I not sure if something special is done when adding a C++ object during linking. Hope this helps finding actual problem. I can confirm this bug (of gdb), too. I use emacs/GUD. The crash does not occur when setting the catch point but only when break points are displayed. This happens with "gdb -i=mi" same way as with "gdb --fullname" I created a bug report for this towards gdb http://sourceware.org/bugzilla/show_bug.cgi?id=13898 Sorry I referenced the wrong bug. The right one is http://sourceware.org/bugzilla/show_bug.cgi?id=15468 Can we close as upstream bug, then? From my point of view: yes. Remark: Workaround is to use "break __cxa_throw" instead of "catch throw" |