Debugging while building the documentation

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Debugging while building the documentation

Pantxo
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?

Pantxo 
Reply | Threaded
Open this post in threaded view
|

Re: Debugging while building the documentation

Dmitri A. Sergatskov


On Wed, Nov 7, 2018 at 5:03 AM Pantxo Diribarne <[hidden email]> 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
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)


Pantxo 

Dmitri.
--
Reply | Threaded
Open this post in threaded view
|

Re: Debugging while building the documentation

John W. Eaton
Administrator
On 11/07/2018 12:00 PM, Dmitri A. Sergatskov wrote:

>
>
> On Wed, Nov 7, 2018 at 5:03 AM Pantxo Diribarne
> <[hidden email] <mailto:[hidden email]>> 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

Reply | Threaded
Open this post in threaded view
|

Re: Debugging while building the documentation

Pantxo
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
>> <[hidden email] <mailto:[hidden email]>> 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

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.

Pantxo