3
edits
Debugging Octave: Difference between revisions
Jump to navigation
Jump to search
→Producing a stack trace
BabakRz63ai (talk | contribs) |
BabakRz63ai (talk | contribs) |
||
| Line 75: | Line 75: | ||
== Producing a stack trace == | == Producing a stack trace == | ||
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. | 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 , only if you can afford such a huge work, 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. | ||
But if you can't or don't want to recompile octave ,which is totally normal, then you can 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 can be stored somewhere in the directory tree. You should find them, view them and inspect them. | |||
=== Where are core dumps stored? === | |||
It differs on each system. First you should see what does handle core dumps on your system. to do so, type this in a shell terminal: | |||
<syntaxhighlight lang="bash"> | |||
$ cat /proc/sys/kernel/core_pattern | |||
</syntaxhighlight> | |||
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? === | |||
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"> | |||
gdb octave -c <Path to core dump> | |||
</syntaxhighlight> | |||
Always expect some warnings from gdb in a few first times of doing this. Most likely gdb will tell you that: | |||
1. The core dump file is not in the correct format. It is the case if the core dump handler of your system compresses core dumps before storing them, and you need to decompress the core dump first. | |||
2. Core was generated by a-path-to/octave-gui. Then quit gdb and start it again by: | |||
<syntaxhighlight lang="bash"> | |||
gdb octave-gui -c <Path to core dump> | |||
</syntaxhighlight> | |||
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 'where' command in gdb prompt to see a full stack trace of the crash. | |||
=== Most used commands === | === Most used commands === | ||