KDevelop5/Manual/Debugging programs/en: Difference between revisions

From KDE UserBase Wiki
(Importing a new version from external source)
 
(Updating to match new version of source page)
Line 7: Line 7:
Once you have a launch configured (see [[Special:myLanguage/KDevelop5/Manual/Running programs|Running programs]]), you can also run it in a debugger: Select the menu item <menuchoice>Run -> Debug Launch</menuchoice>, or hit <keycap>F9</keycap>. If you are familiar with '''gdb''', the effect is the same as starting '''gdb''' with the executable specified in the launch configuration and then saying <code>Run</code>. This means that if the program calls <code>abort()</code> somewhere (e.g. when you run onto a failing assertion) or if there is a segmentation fault, then the debugger will stop. On the other hand, if the program runs to the end (with or without doing the right thing) then the debugger will not stop by itself before the program is finished. In the latter case, you will want to set a breakpoint on all those lines of your code base where you want the debugger to stop before you run the debug launch. You can do that by moving the cursor on such a line and selecting the menu item <menuchoice>Run -> Toggle breakpoint</menuchoice>, or right-clicking on a line and selecting <menuchoice>Toggle Breakpoint</menuchoice> from the context menu.
Once you have a launch configured (see [[Special:myLanguage/KDevelop5/Manual/Running programs|Running programs]]), you can also run it in a debugger: Select the menu item <menuchoice>Run -> Debug Launch</menuchoice>, or hit <keycap>F9</keycap>. If you are familiar with '''gdb''', the effect is the same as starting '''gdb''' with the executable specified in the launch configuration and then saying <code>Run</code>. This means that if the program calls <code>abort()</code> somewhere (e.g. when you run onto a failing assertion) or if there is a segmentation fault, then the debugger will stop. On the other hand, if the program runs to the end (with or without doing the right thing) then the debugger will not stop by itself before the program is finished. In the latter case, you will want to set a breakpoint on all those lines of your code base where you want the debugger to stop before you run the debug launch. You can do that by moving the cursor on such a line and selecting the menu item <menuchoice>Run -> Toggle breakpoint</menuchoice>, or right-clicking on a line and selecting <menuchoice>Toggle Breakpoint</menuchoice> from the context menu.


[[Image:kdevelop-4.png|center|thumb|550px]]
[[File:Kdevelop-debug-bus-main.png|550px|thumb|center]]


Running a program in the debugger will put '''KDevelop''' in a different mode: it will replace all the "Tool" buttons on the perimeter of the main window by ones that are appropriate for debugging, rather than for editing. You can see which of the mode you are in by looking at the top right of the window: there are tabs named <menuchoice>Review</menuchoice>, <menuchoice>Debug</menuchoice>, and <menuchoice>Code</menuchoice>; clicking on them allows you to switch back and forth between the three modes; each mode has a set of tool views of its own, which you can configure in the same way as we configured the <menuchoice>Code</menuchoice> tools in the section [[KDevelop5/Manual/Working_with_source_code#Tools and views|Tools and views]].
Running a program in the debugger will put '''KDevelop''' in a different mode: it will replace all the "Tool" buttons on the perimeter of the main window by ones that are appropriate for debugging, rather than for editing. You can see which of the modes you are in by looking at the top right of the window: there is a button named <menuchoice>Code</menuchoice> in ''editing'' mode, and a button named <menuchoice>Debug</menuchoice> in ''debugging'' mode; clicking on them allows you to switch back and forth between the two modes; each mode has a set of tool views of its own, which you can configure in the same way as we configured the <menuchoice>Code</menuchoice> tools in the section [[KDevelop5/Manual/Working_with_source_code#Tools and views|Tools and views]].


Once the debugger stops (at a breakpoint, or a point where <code>abort()</code> is called) you can inspect a variety of information about your program. For example, in the image above, we have selected the <menuchoice>Frame Stack</menuchoice> tool at the bottom (roughly equivalent to '''gdb's''' "backtrace" and "info threads" commands) that shows the various threads that are currently running in your program at the left (here a total of 8) and how execution got to the current stopping point at the right (here: <code>main()</code> called <code>run()</code>; the list would be longer had we stopped in a function called by <code>run()</code> itself). On the left, we can inspect local variables including the current object (the object pointed to by the <code>this</code> variable).
Once the debugger stops (at a breakpoint, or a point where <code>abort()</code> is called) you can inspect a variety of information about your program. For example, in the image above, we have selected <menuchoice>Debug</menuchoice> to show the programs output. The <menuchoice>Frame Stack</menuchoice> tool at the bottom (roughly equivalent to '''gdb's''' "backtrace" and "info threads" commands) that shows the various threads that are currently running in your program at the left, and how execution got to the current stopping point at the right (here: <code>main()</code> called <code>Bus bus;</code>; the list would be longer had we stopped in a function called by <code>bus</code> itself). On the left, we can inspect local variables including the current object (the object pointed to by the <code>this</code> variable).


From here, there are various possibilities you can do: You can execute the current line (<keycap>F10</keycap>, '''gdb's''' "next" command), step into the functions (<keycap>F11</keycap>, '''gdb's''' "step" command), or run to the end of the function (<keycap>F12</keycap>, '''gdb's''' "finish" command). At every stage, '''KDevelop''' updates the variables shown at the left to their current values. You can also hover the mouse over a symbol in your code, e.g. a variable; '''KDevelop''' will then show the current value of that symbol and offer to stop the program during execution the next time this variable's value changes. If you know '''gdb''', you can also click on the <menuchoice>GDB</menuchoice> tool button at the bottom and have the possibility to enter '''gdb''' commands, for example in order to change the value of a variable (for which there doesn't currently seem to be another way).
From here, there are various possibilities you can do: You can execute the current line (<keycap>F10</keycap>, '''gdb's''' "next" command), step into the functions (<keycap>F11</keycap>, '''gdb's''' "step" command), or run to the end of the function (<keycap>F12</keycap>, '''gdb's''' "finish" command). At every stage, '''KDevelop''' updates the variables shown at the left to their current values. You can also hover the mouse over a symbol in your code, e.g. a variable; '''KDevelop''' will then show the current value of that symbol and offer to stop the program during execution the next time this variable's value changes. If you know '''gdb''', you can also click on the <menuchoice>GDB</menuchoice> tool button at the bottom and have the possibility to enter '''gdb''' commands, for example in order to change the value of a variable (for which there doesn't currently seem to be another way).
Line 19: Line 19:
[[Image:kdevelop-9.png|center|thumb|300px]]
[[Image:kdevelop-9.png|center|thumb|300px]]


Sometimes, one wants to debug a program that's already running. One scenario for this is debugging parallel programs using [https://computing.llnl.gov/tutorials/mpi/ MPI], or for debugging a long running background process. To do this, go to the menu entry <menuchoice>Run -> Attach to Process</menuchoice>, which will open a window like the one above. You will want to select the program that matches your currently open project in '''KDevelop''' - in my case that would be the step-32 program.  
Sometimes, one wants to debug a program that's already running. One scenario for this is debugging parallel programs using [https://computing.llnl.gov/tutorials/mpi/ MPI], or for debugging a long running background process. To do this, go to the menu entry <menuchoice>Run -> Attach to Process</menuchoice>, which will open a window like the one above. You will want to select the program that matches your currently open project in '''KDevelop''' - in my case that would be the step-32 program.
 
[[File:Kdevelop-attach-to-process-refuse.png|500px|thumb|center]]
 
Attaching a debugger to a running program is not allowed by default on most
Linux distributions. To do so, you first need to know a little about
''PTRACE'' system that is used for debugging. Generally, the default setting is a
scope of "1", which limits PTRACE to direct child processes only (e.g. "gdb
name-of-program" and "strace -f name-of-program" work, but gdb's "attach"
and "strace -fp $PID" do not). A PTRACE scope of "0" is the more permissive
mode.
 
There are two ways to change this on Ubuntu, if you are running a different distribution, your requirements may be different. On Ubuntu, one way is to edit the
<tt>/etc/sysctl.d/10-ptrace.conf</tt> file and change <tt>kernel.yama.ptrace_scope</tt> to 0.
After editing the file run the following command:
{{Input|1=<nowiki>sudo service procps restart</nowiki>}} You should now be able to attach to a running process.
 
The other way that is the more secure way is to run:
{{Input|1=<nowiki>echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope</nowiki>}}
when you want to use the feature, and:
{{Input|1=<nowiki>echo 1 | sudo tee /proc/sys/kernel/yama/ptrace_scope</nowiki>}}
when you have completed your need for attaching to a running process.
 
After setting your <tt>ptrace_scope</tt> to 0, you will want to select the program that matches your currently open project in '''KDevelop'''.


This list of programs can be confusing because it is often long as in the case shown here. You can make your life a bit easier by going to the dropdown box at the top right of the window. The default value is <menuchoice>User processes</menuchoice>, i.e. all programs that are run by any of the users currently logged into this machine (if this is your desktop or laptop, you're probably the only such user, apart from root and various service accounts); the list doesn't include processes run by the root user, however. You can limit the list by either choosing <menuchoice>Own processes</menuchoice>, removing all the programs run by other users. Or better still: Select <menuchoice>Programs only</menuchoice>, which removes a lot of processes that are formally running under your name but that you don't usually interact with, such as the window manager, background tasks and so on that are unlikely candidates for debugging.
This list of programs can be confusing because it is often long as in the case shown here. You can make your life a bit easier by going to the dropdown box at the top right of the window. The default value is <menuchoice>User processes</menuchoice>, i.e. all programs that are run by any of the users currently logged into this machine (if this is your desktop or laptop, you're probably the only such user, apart from root and various service accounts); the list doesn't include processes run by the root user, however. You can limit the list by either choosing <menuchoice>Own processes</menuchoice>, removing all the programs run by other users. Or better still: Select <menuchoice>Programs only</menuchoice>, which removes a lot of processes that are formally running under your name but that you don't usually interact with, such as the window manager, background tasks and so on that are unlikely candidates for debugging.

Revision as of 14:31, 6 September 2020

Other languages:

Debugging programs in KDevelop

Running a program in the debugger

Once you have a launch configured (see Running programs), you can also run it in a debugger: Select the menu item Run -> Debug Launch, or hit F9. If you are familiar with gdb, the effect is the same as starting gdb with the executable specified in the launch configuration and then saying Run. This means that if the program calls abort() somewhere (e.g. when you run onto a failing assertion) or if there is a segmentation fault, then the debugger will stop. On the other hand, if the program runs to the end (with or without doing the right thing) then the debugger will not stop by itself before the program is finished. In the latter case, you will want to set a breakpoint on all those lines of your code base where you want the debugger to stop before you run the debug launch. You can do that by moving the cursor on such a line and selecting the menu item Run -> Toggle breakpoint, or right-clicking on a line and selecting Toggle Breakpoint from the context menu.

Running a program in the debugger will put KDevelop in a different mode: it will replace all the "Tool" buttons on the perimeter of the main window by ones that are appropriate for debugging, rather than for editing. You can see which of the modes you are in by looking at the top right of the window: there is a button named Code in editing mode, and a button named Debug in debugging mode; clicking on them allows you to switch back and forth between the two modes; each mode has a set of tool views of its own, which you can configure in the same way as we configured the Code tools in the section Tools and views.

Once the debugger stops (at a breakpoint, or a point where abort() is called) you can inspect a variety of information about your program. For example, in the image above, we have selected Debug to show the programs output. The Frame Stack tool at the bottom (roughly equivalent to gdb's "backtrace" and "info threads" commands) that shows the various threads that are currently running in your program at the left, and how execution got to the current stopping point at the right (here: main() called Bus bus;; the list would be longer had we stopped in a function called by bus itself). On the left, we can inspect local variables including the current object (the object pointed to by the this variable).

From here, there are various possibilities you can do: You can execute the current line (F10, gdb's "next" command), step into the functions (F11, gdb's "step" command), or run to the end of the function (F12, gdb's "finish" command). At every stage, KDevelop updates the variables shown at the left to their current values. You can also hover the mouse over a symbol in your code, e.g. a variable; KDevelop will then show the current value of that symbol and offer to stop the program during execution the next time this variable's value changes. If you know gdb, you can also click on the GDB tool button at the bottom and have the possibility to enter gdb commands, for example in order to change the value of a variable (for which there doesn't currently seem to be another way).

Attaching the debugger to a running process

Sometimes, one wants to debug a program that's already running. One scenario for this is debugging parallel programs using MPI, or for debugging a long running background process. To do this, go to the menu entry Run -> Attach to Process, which will open a window like the one above. You will want to select the program that matches your currently open project in KDevelop - in my case that would be the step-32 program.

Attaching a debugger to a running program is not allowed by default on most Linux distributions. To do so, you first need to know a little about PTRACE system that is used for debugging. Generally, the default setting is a scope of "1", which limits PTRACE to direct child processes only (e.g. "gdb name-of-program" and "strace -f name-of-program" work, but gdb's "attach" and "strace -fp $PID" do not). A PTRACE scope of "0" is the more permissive mode.

There are two ways to change this on Ubuntu, if you are running a different distribution, your requirements may be different. On Ubuntu, one way is to edit the /etc/sysctl.d/10-ptrace.conf file and change kernel.yama.ptrace_scope to 0. After editing the file run the following command: 

sudo service procps restart

You should now be able to attach to a running process.

The other way that is the more secure way is to run: 

echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope

when you want to use the feature, and: 

echo 1 | sudo tee /proc/sys/kernel/yama/ptrace_scope

when you have completed your need for attaching to a running process.

After setting your ptrace_scope to 0, you will want to select the program that matches your currently open project in KDevelop.

This list of programs can be confusing because it is often long as in the case shown here. You can make your life a bit easier by going to the dropdown box at the top right of the window. The default value is User processes, i.e. all programs that are run by any of the users currently logged into this machine (if this is your desktop or laptop, you're probably the only such user, apart from root and various service accounts); the list doesn't include processes run by the root user, however. You can limit the list by either choosing Own processes, removing all the programs run by other users. Or better still: Select Programs only, which removes a lot of processes that are formally running under your name but that you don't usually interact with, such as the window manager, background tasks and so on that are unlikely candidates for debugging.

Once you have selected a process, attaching to it will get you into KDevelop's debug mode, open all the usual debugger tool views and stop the program at the position where it happened to be when you attached to it. You may then want to set breakpoints, viewpoints, or whatever else is necessary and continue program execution by going to the menu item Run -> Continue.

Some useful keyboard shortcuts

Debugging
F10 Step over (gdb's "next")
F11 Step into (gdb's "step")
F12 Step out of (gdb's "finish")
Retrieved from "https://userbase.kde.org/index.php?title=KDevelop5/Manual/Debugging_programs/en&oldid=458997"