Editing Debugging Octave
Jump to navigation
Jump to search
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.
Latest revision | Your text | ||
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 10: | Line 9: | ||
</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 optimisations (no -O2 gcc parameter) and with debug symbols compiled in. This build is useful for debugging Octave itself. | ||
= | = Debugging Source files without GUI= | ||
Ubuntu introduced a patch to disallow ptracing of non-child processes by non-root users - ie. only a process which is a parent of another process can ptrace it for normal users - whilst root can still ptrace every process. | |||
That's why gdb won't be able to link to the octave process if you start gdb from within an Octave session using the command | |||
<syntaxhighlight lang="bash"> | |||
octave> system (sprintf ("gnome-terminal --command 'gdb -p %d'", getpid ()), "async"); | |||
</syntaxhighlight> | |||
You can temporarily disable this restriction by doing: | You can temporarily disable this restriction by doing: | ||
Line 31: | Line 24: | ||
echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope | echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope | ||
</syntaxhighlight> | </syntaxhighlight> | ||
and then reopen | and then reopen the gdb using the command mentioned above from within an Octave session or if you have admin right you can simply do: | ||
<syntaxhighlight lang="bash"> | |||
octave> system (sprintf ("gnome-terminal --command 'sudo gdb -p %d'", getpid ()), "async"); | |||
</syntaxhighlight> | |||
Instead you can debug octave without gui using: | |||
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
./run-octave -g --no-gui | |||
</syntaxhighlight> | </syntaxhighlight> | ||
Line 44: | Line 44: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
start now the GNU debugger with octave. On most Unixy systems, you can start gdb from within an Octave session by evaluating a command like | |||
<syntaxhighlight lang="bash"> | |||
octave> system (sprintf ("gnome-terminal --command 'gdb -p %d'", getpid ()), "async"); | |||
</syntaxhighlight> | |||
at the Octave prompt. This command will open a terminal window running gdb attached to the Octave process. At this point, Octave will be stopped. To tell Octave to continue, type | |||
<syntaxhighlight lang="bash"> | |||
(gdb) continue | |||
</syntaxhighlight> | |||
at the gdb prompt. The symbols from your oct-file will only be available to gdb once the oct-file is loaded in Octave. To do that without executing any functions from the oct-file, you can ask Octave to display the help for the oct-file: | |||
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
Line 50: | Line 62: | ||
</syntaxhighlight> | </syntaxhighlight> | ||
Now halt execution of Octave by typing ctrl+c, you'll see again the gdb prompt. Set now a breakpoint in the line of interest | |||
<syntaxhighlight lang="bash"> | <syntaxhighlight lang="bash"> | ||
Line 66: | Line 76: | ||
the debugger will stop on the above defined line and you can start debugging according to the manual of GNU debugger. | the debugger will stop on the above defined line and you can start debugging according to the manual of GNU debugger. | ||
= Tools for debugging = | |||
== Producing a stack trace == | == Producing a stack trace == | ||
Sometimes Octave | Sometimes Octave will 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. To do so, you need to (re)compile Octave with debugging symbols and run the debugger, as explained above. Then execute whatever commands are necessary to cause Octave to crash. At that point, you will be back in a gdb session. Type <code>where</code> at the gdb prompt to obtain a stack trace. | ||
=== Most used commands === | |||
[http://www.gnu.org/software/gdb/documentation gdb documentation] | [http://www.gnu.org/software/gdb/documentation gdb documentation] | ||
For debugging octave_value variables to find out what the variable actually is (instead of just it's base class): | |||
For debugging octave_value variables | |||
<code>(gdb) print *(my_octave_value.rep)</code> | |||
* | |||
== ddd == | == ddd == | ||
[http://www.gnu.org/software/ddd gui for gdb] | |||
[http://www.gnu.org/software/ddd | |||
[[Category:Development]] | [[Category:Development]] |