Version: 4.2.3 (using KDE 4.7.3) OS: Linux When I watch a variable and open the '+' sign, the debugger suddenly exits. I turned on the debug for all kdevelop components and attach the log from when I open the '+' sign until it goes back to code window, Reproducible: Sometimes Steps to Reproduce: Watching a variable causes the debugger to exit. I have to upload the whole project to say the steps to reproduce Actual Results: The debugger terminates unexpectedly Expected Results: I must see the variable's value
The bug is reproducible but not a duplicate.
Could you please provide a backtrace?
KDevelop doesn't crash, right? It's gdb that is stopping or crashing. Best would be if you could provide exact steps to reproduce using an simplified test case. Or if you are debugging an open source project point us to the code.
Kdevelop doesn't crash. However the process is still running and consumes cpu usage. Hope that I clearly state the problem. The code is open source and you can download it (http://repo.gem5.org/gem5/) however setting up command line options and workloads are somehow difficult. The code uses "scons". So I built is from terminal and give the binary to my launch. I attached a log file but can not see that is in this page. Did you receive the attachment?
Created attachment 66668 [details] gdb log for kdevelop I upload another log that may be useful for developers. Please see "GDB ERRORED 1" message inside the file. Also please note that the variable I want to watch is pointer
ah, useful information. GDB ERRORED 1 means the gdb process crashed (1 = QProcess::Crashed). I'd say it's a gdb bug. It should be possible to reproduce this crash using plain gdb - by executing the commands from the log file (GDB::execute: SEND:). If you can, start gdb inside gdb (yeah confusing...) and try to get a backtrace. One possible cause for this could be the pretty printers kdevelop uses.
Sorry What should I do exactly to reproduce that? You mean: 1- start GDB from terminal. 2- (gdb) GDB::execute: SEND: but I get Undefined command: "GDB"
I mean the lines starting with "GDBDebugger::GDB::execute: SEND: ", those are the commands that are actually sent to the debugger. Yes there will be a lot of them - easiest is to extract those using a texteditor and the paste them. oh, and start with gdb --interpreter=mi2
the following commands causes gdb crash inside kdevelop: -exec-continue -thread-info -stack-list-frames --thread 1 --frame 0 0 21 -var-create --thread 1 --frame 0 var24 @ "peer" -stack-list-locals --thread 1 --frame 0 --simple-values -var-update --thread 1 --frame 0 --all-values * -break-list -stack-list-arguments --thread 1 --frame 0 0 0 0 -var-list-children --thread 1 --frame 0 --all-values "var22" 0 5 -var-list-children --thread 1 --frame 0 --all-values "var18" 0 5 -var-delete "var19" -var-delete "var20" -var-create --thread 1 --frame 0 var25 @ "ic" -var-create --thread 1 --frame 0 var26 @ "dc" -var-create --thread 1 --frame 0 var27 @ "dc2" -var-list-children --thread 1 --frame 0 --all-values "var22.public" -var-list-children --thread 1 --frame 0 --all-values "var22.private" -var-list-children --thread 1 --frame 0 --all-values "var22.protected" -exec-next as soon as "-exec-next" is executed, the kdevelop return to code window and the debugger terminates. I think there is something wrong with viewing "public", "private" and "protected" variables for a pointer.
you need to do this in commandline gdb, outside of kdevelop. Else we don't know for sure if it's kdevelop's fault or gdb's fault. You are missing all the initialisation commands including breakpoint settings.
Problem is another thing with starting gdb alone... consider in kdevelop I can do this: 1- launch debugger and let it run until reach a breakpoint 2- then I mnually watch a pointer variable, say "Ptr" 3- now exit the debugger by pressing stop. imagine every thing is normal here. Then I relaunch the debugger. Now as soon as I enter the debug window, I can see that the variable "Ptr" is remained from the previous debug. While the program is run and not reached the breakpoint, the varible and its values and fields are gray in color. In short, with kdevelop a watched variable will remain in debug session. So How can I do that in gdb alone. Hope that I clearly state the problem.
I don't think that this is the cause for your problem. The thing is that gdb crashes. That should never happen - it's very likely a bug in gdb. As I said to track down the issue you should try to reproduce the crash in plain gdb (without kdevelop) by executing the same commands kdevelop does.
Commands in plain gdb are different from what I inserted in kdevelop. There is no "-exec-continue". Instead I should use "continue" There is no "-thread-info". Instead I should use "info thread" I can not find the equivalent for -stack-list-frames and others.
use -exec-continue, that works if you start gdb with --interpreter=mi2
ok. I did that. I use the following command gdb --interpreter=mi2 --args <command> <options> (gdb) break build/X86_SE/cpu/base.cc:412 &"break build/X86_SE/cpu/base.cc:412\n" ~"Breakpoint 1 at 0x6bb9f0: file build/X86_SE/cpu/base.cc, line 412.\n" ^done (gdb) -exec-continue ^error,msg="The program is not being run." (gdb) run &"run\n" .... <<<<program outputs>>>>> ~"\nBreakpoint " ~"1, BaseCPU::takeOverFrom (this=0x2387e50, oldCPU=0x24ee1c0, ic=0x2356650, dc=0x238a178, dc2=0x23b7700) at build/X86_SE/cpu/base.cc:412\n" ~"412\t if (!ic->isConnected()) {\n" *stopped,frame={addr="0x00000000006bb9f0",func="BaseCPU::takeOverFrom",args=[{name="this",value="0x2387e50"},{name="oldCPU",value="0x24ee1c0"},{name="ic",value="0x2356650"},{name="dc",value="0x238a178"},{name="dc2",value="0x23b7700"}],file="build/X86_SE/cpu/base.cc",fullname="/home/mahmood/gem5/build/X86_SE/cpu/base.cc",line="412"},thread-id="1",stopped-threads="all",core="1" (gdb) -thread-info ^done,threads=[{id="1",target-id="Thread 0x7ffff7fe1740 (LWP 2372)",name="m5.debug",frame={level="0",addr="0x00000000006bb9f0",func="BaseCPU::takeOverFrom",args=[{name="this",value="0x2387e50"},{name="oldCPU",value="0x24ee1c0"},{name="ic",value="0x2356650"},{name="dc",value="0x238a178"},{name="dc2",value="0x23b7700"}],file="build/X86_SE/cpu/base.cc",fullname="/home/mahmood/gem5/build/X86_SE/cpu/base.cc",line="412"},state="stopped",core="1"}],current-thread-id="1" (gdb) -stack-list-frames --thread 1 --frame 0 0 21 ^done,stack=[frame={level="0",addr="0x00000000006bb9f0",func="BaseCPU::takeOverFrom",file="build/X86_SE/cpu/base.cc",fullname="/home/mahmood/gem5/build/X86_SE/cpu/base.cc",line="412"},frame={level="1",addr="0x00000000007378fe",func="FullO3CPU<O3CPUImpl>::takeOverFrom",file="build/X86_SE/cpu/o3/cpu.cc",fullname="/home/mahmood/gem5/build/X86_SE/cpu/o3/cpu.cc",line="1177"},frame={level="2",addr="0x0000000000f76865",func="_wrap_SimObject_takeOverFrom",file="build/X86_SE/python/m5/internal/param_SimObject_wrap.cc",fullname="/home/mahmood/gem5/build/X86_SE/python/m5/internal/param_SimObject_wrap.cc",line="3237"},frame={level="3",addr="0x00007ffff77bc0ee",func="PyEval_EvalFrameEx",from="/usr/lib/libpython2.7.so.1.0"},frame={level="4",addr="0x00007ffff77bdf05",func="PyEval_EvalCodeEx",from="/usr/lib/libpython2.7.so.1.0"},frame={level="5",addr="0x00007ffff77bc075",func="PyEval_EvalFrameEx",from="/usr/lib/libpython2.7.so.1.0"},frame={level="6",addr="0x00007ffff77bdf05",func="PyEval_EvalCodeEx",from="/usr/lib/libpython2.7.so.1.0"},frame={level="7",addr="0x00007ffff77bc075",func="PyEval_EvalFrameEx",from="/usr/lib/libpython2.7.so.1.0"},frame={level="8",addr="0x00007ffff77bdf05",func="PyEval_EvalCodeEx",from="/usr/lib/libpython2.7.so.1.0"},frame={level="9",addr="0x00007ffff77bc075",func="PyEval_EvalFrameEx",from="/usr/lib/libpython2.7.so.1.0"},frame={level="10",addr="0x00007ffff77bd064",func="PyEval_EvalFrameEx",from="/usr/lib/libpython2.7.so.1.0"},frame={level="11",addr="0x00007ffff77bdf05",func="PyEval_EvalCodeEx",from="/usr/lib/libpython2.7.so.1.0"},frame={level="12",addr="0x00007ffff77be042",func="PyEval_EvalCode",from="/usr/lib/libpython2.7.so.1.0"},frame={level="13",addr="0x00007ffff77bc5e9",func="PyEval_EvalFrameEx",from="/usr/lib/libpython2.7.so.1.0"},frame={level="14",addr="0x00007ffff77bdf05",func="PyEval_EvalCodeEx",from="/usr/lib/libpython2.7.so.1.0"},frame={level="15",addr="0x00007ffff77bc075",func="PyEval_EvalFrameEx",from="/usr/lib/libpython2.7.so.1.0"},frame={level="16",addr="0x00007ffff77bdf05",func="PyEval_EvalCodeEx",from="/usr/lib/libpython2.7.so.1.0"},frame={level="17",addr="0x00007ffff77be042",func="PyEval_EvalCode",from="/usr/lib/libpython2.7.so.1.0"},frame={level="18",addr="0x00007ffff77e04bc",func="PyRun_StringFlags",from="/usr/lib/libpython2.7.so.1.0"},frame={level="19",addr="0x000000000065d322",func="m5Main",file="build/X86_SE/sim/init.cc",fullname="/home/mahmood/gem5/build/X86_SE/sim/init.cc",line="256"},frame={level="20",addr="0x00000000004099ab",func="main",file="build/X86_SE/sim/main.cc",fullname="/home/mahmood/gem5/build/X86_SE/sim/main.cc",line="57"}] (gdb) -var-create --thread 1 --frame 0 var24 @ "peer" ^error,msg="-var-create: unable to create variable object" (gdb) Please note that I couldn't use "-exec-continue" and watching the variable "peer" is not possible. Any idea?
You didn't run your program. Execute all commands kdevelop does! (you have just the last few ones)
I did that. please see (gdb) run &"run\n"
ah, I didn't see that. You should still execute the *exactly same* commands as kdevelop does! To get them run your application until you get the gdb crash. Then open GDB tool view, right click, activate Show Internal Commands and copy the text. Then extract all the blue lines starting with (gdb). Those are the commands kdevelop sends to gdb. And you can do the same manually - whithout kdevelop. don't use "run" or "break" just do as kdevelop does...