216
edits
Debugging Octave: Difference between revisions
Jump to navigation
Jump to search
→Tools for debugging: __debug_octave__ is in released versions now
(→Tools for debugging: Restore instructions for attaching gdb to Octave from an "independent" shell.) |
(→Tools for debugging: __debug_octave__ is in released versions now) |
||
| (One intermediate revision by one other user not shown) | |||
| Line 1: | Line 1: | ||
= Preliminaries = | = Preliminaries = | ||
Since compilation of all the source from scratch can take long it is good to have a source folder where most of the source has been compiled. To do this, you can create a parallel build: | Since compilation of all the source from scratch can take long it is good to have a source folder where most of the source has been compiled. To do this, you can create a parallel build: | ||
| Line 9: | Line 10: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
This will create a new build of Octave in a different directory without | This will create a new build of Octave in a different directory without optimizations (no -O2 gcc parameter) and with debug symbols compiled in. This build is useful for debugging Octave itself. | ||
= Tools for debugging = | = Tools for debugging = | ||
There are different tools for debugging. This article concentrates on describing how to use <code>gdb</code>. | 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). Note that when Octave runs in GUI mode, it forks at startup on Linux and MacOS systems, so this method will only work if <code>gdb</code> correctly follows the process across the <code>fork</code> and <code>exec</code> system calls. | 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). Note that when Octave runs in GUI mode, it forks at startup on Linux and MacOS systems, so this method will only work if <code>gdb</code> correctly follows the process across the <code>fork</code> and <code>exec</code> system calls. | ||
Alternatively, you can attach a debugger to a running Octave session. Current | Alternatively, you can attach a debugger to a running Octave session. Current versions of Octave include the command <code>__debug_octave__</code> to manage the details. Executing this command at the Octave prompt should open a separate window for a debugger session attached to the current Octave process. On Linux systems, the default terminal window is <code>gnome-terminal</code>. On MacOS systems, the default debugger is <code>lldb</code>. | ||
For some kinds of errors on some OS, the last approach might not be useful. The OS might kill the shell that runs gdb as soon as the spawning process (i.e. Octave) crashes. In that case, you can attach to Octave from an "independent" shell. Execute <code>getpid ()</code> in Octave and take note of the displayed *PID*. Open a shell and execute <code>gdb -p *PID*</code> (replace <code>*PID*</code> with the actual PID). On Windows, use the msys2 shell that can be started with the file <code>cmdshell.bat</code> in Octave's installation folder. | For some kinds of errors on some OS, the last approach might not be useful. The OS might kill the shell that runs gdb as soon as the spawning process (i.e. Octave) crashes. In that case, you can attach to Octave from an "independent" shell. Execute <code>getpid ()</code> in Octave and take note of the displayed *PID*. Open a shell and execute <code>gdb -p *PID*</code> (replace <code>*PID*</code> with the actual PID). On Windows, use the msys2 shell that can be started with the file <code>cmdshell.bat</code> in Octave's installation folder. | ||
| Line 75: | Line 77: | ||
=== Where are core dumps stored? === | === Where are core dumps stored? === | ||
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: | 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"> | ||
| Line 82: | Line 85: | ||
=== How to view a core dump? === | === How to view a core dump? === | ||
To do this you should use gdb. Core dumps are saved under root user, so you may need to change owner of the core dump you are interested in if you are not logged in as root. After that type in the terminal: | To do this you should use gdb. Core dumps are saved under root user, so you may need to change owner of the core dump you are interested in if you are not logged in as root. After that type in the terminal: | ||
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
| Line 101: | Line 105: | ||
=== Helpful gdb commands === | === Helpful gdb commands === | ||
[http://www.gnu.org/software/gdb/documentation gdb documentation] | [http://www.gnu.org/software/gdb/documentation gdb documentation] | ||
| Line 120: | Line 125: | ||
== ddd == | == ddd == | ||
[http://www.gnu.org/software/ddd | |||
[http://www.gnu.org/software/ddd GUI for gdb] | |||
[[Category:Development]] | [[Category:Development]] | ||