On 11/07/2018 12:00 PM, Dmitri A. Sergatskov wrote:
On Wed, Nov 7, 2018 at 5:03 AM Pantxo Diribarne
<address@hidden <mailto:address@hidden>> wrote:
Hi,
I am currently experimenting with using std::mutex and
std::unique_lock instead of our system dependent implementation of
mutexes. This is for the context.
I am getting a segfault when building the documentation (when
running genpropdoc.m) which I am not able to reproduce in a normal
run-octave session.
To complicate things, the segfault only happens when building with
"-jN" (N>1).
Hence my question: how can I get a backtrace after a crash that
happens when run-octave is ran from the build system?
On redhat/fedora systemd-coredump
https://www.freedesktop.org/software/systemd/man/systemd-coredump.html
will capture coredumps into system logs.
E.g. if I run something like that:
main()
{
double a[3];
int i;
for (i=1; i++; i< 5) a[i] = 2*i;
return 0;
}
I get a bus error and in the logs I see:
Nov 07 10:34:48 td-119156 systemd-coredump[26177]: Process 26175
(a.out) of user 1001 dumped core.
Stack trace of
thread 26175:
#0
0x0000000000401121 main (a.out)
#1
0x00007fba29fd4413 __libc_start_main (libc.so.6)
#2
0x000000000040104e _start (a.out)
It should also be possible to enable core file creation in your shell
and then run gdb on the executable and the core file to examine the
state of the program at the time of the crash. In bash:
ulimit -c unlimited
./run-octave ...
... provoke crash
Now you should have a core file in the directory where you started
Octave. Then you can run gdb on the octave-gui program and the core
file:
gdb /path/to/octave-gui core
Since running Octave in the build tree requires some environment
variables to be set, this may be easiest if you have a copy of
octave-gui that is installed.
jwe