help-octave
[Top][All Lists]
Advanced

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

Re: octave 3.4.0 on Scientific Linux 5


From: John W. Eaton
Subject: Re: octave 3.4.0 on Scientific Linux 5
Date: Fri, 25 Feb 2011 10:58:45 -0500

On 25-Feb-2011, Michael Martins wrote:

| Thank you for the fast response. Unfortunately I am a little bit helpless 
with 
| this type of error. The machine is a Quadcore Dual Xeon systems running a 
| 64bit SL5.
| 
| All the best
| Michael
| -----
| 
| Here is the backtrace
| 
| GNU gdb Fedora (6.8-27.el5)
| Copyright (C) 2008 Free Software Foundation, Inc.
| License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
| 
| [Thread debugging using libthread_db enabled]
| [New Thread 0x2b10bfb0dc40 (LWP 29863)]
| 
| Program received signal SIGSEGV, Segmentation fault.
| 0x00002b10bd7cabe8 in sigemptyset () from 
| /scratch/martins/octave-3.4.0/src/.libs/liboctinterp-3.4.0.so
| (gdb) bt
| #0  0x00002b10bd7cabe8 in sigemptyset () from 
| /scratch/martins/octave-3.4.0/src/.libs/liboctinterp-3.4.0.so
| #1  0x00002b10bcd87ae1 in octave_set_signal_handler (sig=2, 
| handler=0x2b10bcd88050 <sigint_handler>, restart_syscalls=true) at 
| sighandlers.cc:225
| #2  0x00002b10bcd87baa in octave_catch_interrupts () at sighandlers.cc:460
| #3  0x00002b10bcd87c13 in install_signal_handlers () at sighandlers.cc:529
| #4  0x00002b10bcd5a547 in octave_main (argc=6, argv=0x7fffaddee7c8, 
| embedded=0) at octave.cc:665
| #5  0x0000003897c1d994 in __libc_start_main () from /lib64/libc.so.6
| #6  0x0000000000400659 in _start ()

This appears to be the same as this problem:

https://savannah.gnu.org/bugs/?30685

As I have said in the comments to the bug report, I still have no clue
precisely what is causing this problem, and since I can't reproduce it
on any system I have, someone who can reproduce the problem is going
to have to do some debugging and analysis to find the cause.

Looking at this problem a little more now, I see that the crash is
apparently happening inside the gnulib sigemptyset function, which is
just

  int
  sigemptyset (sigset_t *set)
  {
    *set = 0;
    return 0;
  }

The call to this function is happening with

  gnulib::sigemptyset (&act.sa_mask);

and my guess is that your definition of the sigaction struct has
sa_mask is not compatible with what the gnulib sigemptyset function is
expecting.  So I think this is a gnulib bug.

At the point of the crash, what do you see if you execute the
following gdb commands?

  (gdb) up
  (gdb) ptype act.sa_mask

?

Please follow up by posting this info to the bug report linked above.

Is the gnulib sigprocmask file being compiled on your system?  If so,
please add -save-temps to CFLAGS and compile this file and attach the
resulting sigprocmask.ii file to the bug report.

Can you also determine why the gnulib sigprocmask.c file is being
compiled?  I don't see any information in the config.log file that you
posted that explains why it would be compiled on your system.

Thanks,

jwe


reply via email to

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