[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debugging while building the documentation

From: Pantxo Diribarne
Subject: Re: Debugging while building the documentation
Date: Wed, 7 Nov 2018 21:21:23 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1

Le 07/11/2018 à 20:51, John W. Eaton a écrit :
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:


    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
will capture coredumps into system logs.

E.g. if I run something like that:

         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.


Thanks, the core file was successfully generated. I tried with src/octave-gui in the build tree but gdb doesn't find debug symbols at all. Backtraces look like this:

#0  0x00007f56e7f66bf9 in ?? ()
#1  0x0000000000000001 in ?? ()
#2  0x00005581814f0750 in ?? ()


And unfortunately I can't install the executable. "make install" will first take care of completing the documentation build ... which will crash.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]