238
edits
Debugging Octave: Difference between revisions
→Tools for debugging: Add basic instructions for running gdb with Octave - Put necessity of re-compiling Octave into perspective
BabakRz63ai (talk | contribs) |
(→Tools for debugging: Add basic instructions for running gdb with Octave - Put necessity of re-compiling Octave into perspective) |
||
| Line 73: | Line 73: | ||
= Tools for debugging = | = Tools for debugging = | ||
There are different tools for debugging. This article concentrates on describing how to use <code>gdb</code>. | |||
If you run Octave from a build tree, execute <code>./run-octave -g</code> to start a gdb session that is prepared to run Octave (with the necessary environment correctly set up). | |||
Alternatively, you can attach <code>gdb</code> to a running Octave. For this, execute <code>gdb</code> in a shell. (On Windows, use the msys2 shell that can be started with the file <code>cmdshell.bat</code> in Octave's installation folder). Find the PID of the running Octave process and attach to it from the <code>(gdb)</code> prompt with <code>attach *PID*</code> (replace <code>*PID*</code> with the actual PID). | |||
Yet another possibility is to start <code>gdb</code> using the <code>system</code> command at the Octave prompt. Depending on the used Linux shell, the command might look similar to: | |||
system (sprintf ("gnome-terminal -- gdb -p %d", getpid ()), false, "async"); | |||
On Windows, you can issue: | |||
system (sprintf ("start gdb -p %d", getpid ())); | |||
Independent of how <code>gdb</code> was started and Octave was attached to it, it is now possible to issue gdb commands on the <code>(gdb)</code> prompt. See e.g. the [https://sourceware.org/gdb/download/onlinedocs/gdb/index.html gdb documentation]. To return to Octave while gdb is still attached to it, execute <code>continue</code> (or <code>c</code>) at the <code>(gdb)</code> prompt. | |||
== Producing a stack trace == | == Producing a stack trace == | ||
Sometimes Octave | Sometimes Octave might crash, meaning, it terminates abruptly and returns control to the operating system shell. In these cases, it is very helpful to produce a stack trace to diagnose the problem. For this, it can be useful to (re)compile Octave with debugging symbols. Otherwise, the stack trace can be harder to read and optimizations might make debugging more difficult. (But it is also possible to produce a stack trace with a "standard" build.) | ||
Attach <code>gdb</code> to Octave as described before and return execution to Octave. Then, execute whatever commands are necessary to cause Octave to crash. At that point, you will be back in the gdb session. Type <code>where</code> or <code>bt</code> at the gdb prompt to obtain a stack trace. | |||
You could also get some help from your system tools. In most GNU/Linux systems whenever a crash happens in a software, a <i>core dump</i> will be generated. These core dumps are handled by a registered component of the system and finally might be stored somewhere in the directory tree. You should find them, view them and inspect them. | |||
=== Where are core dumps stored? === | === Where are core dumps stored? === | ||
It differs on each system. First you should see | It differs on each system. First you should see how core dumps are handled on your system. To do so, type this in a shell terminal: | ||
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
$ cat /proc/sys/kernel/core_pattern | $ cat /proc/sys/kernel/core_pattern | ||
</syntaxhighlight> | </syntaxhighlight> | ||
This may print a file name pattern along with a path | This may print a file name pattern along with a path where all core dumps will be saved <b>ONLY</b> if it does not start by a pipe or '|'. If it does, <i>the kernel will treat the rest of the pattern as a command to run. The core dump will be written to the standard input of that program instead of to a file</i>, and you need to consult that program's help or manual. | ||
=== How to view a core dump? === | === How to view a core dump? === | ||
| Line 103: | Line 118: | ||
3. Some debug info are missing. In this case gdb itself will tell you how to install them. Install them and start gdb again. | 3. Some debug info are missing. In this case gdb itself will tell you how to install them. Install them and start gdb again. | ||
If everything worked fine, you can use | If everything worked fine, you can use <code>where</code> command in gdb prompt to see a full stack trace of the crash. | ||
=== | === Helpful gdb commands === | ||
[http://www.gnu.org/software/gdb/documentation gdb documentation] | [http://www.gnu.org/software/gdb/documentation gdb documentation] | ||