[Octave-bug-tracker] [bug #30685] Segmentation fault in ./run-octave [sigemptyset() in liboctinterp-3.3.52.so]

[Keith Godfrey]

Follow-up Comment #28, bug #30685 (project octave):

addendum to last post:

(to start) != (to run)

This 'solution' is unstable. Examining the problem further, the call to
gnulib::sigprocmask() (from macro sighandlers.cc::BLOCK_SIGNAL) also fails. 

I'm new to debugging large projects, so please forgive me if I'm way off the
mark here, but perhaps this problem relates to an incompatibility between
/usr/include and octave/libgnu?

In libgnu, sigset_t seems assumed to be an integer:

  # if !GNULIB_defined_sigset_t
  typedef unsigned int sigset_t;

The functions in libgnu/sigprocmask.c look like they're expecting sigset_t to
be an int as well. (see code for libgnu's sigemptyset() below)

/usr/include/bits/sigset.h, on the other hand, declares sigset_t to be a
struct holding an array:

  # define _SIGSET_NWORDS (1024 / (8 * sizeof (unsigned long int)))
  typedef struct
    {
      unsigned long int __val[_SIGSET_NWORDS];
    } __sigset_t;

and in /usr/include/signal.h
  typedef __sigset_t sigset_t;

When octave compiles, it uses the /usr/include/bits/sigset.h version of
sigset_t, so the libgnu signal calls are passed the pointer to a struct/array
instead of a pointer to an int (I've confirmed this by setting a break in
sighandlers.cc:octave_set_signal_handler). This incompatibility isn't likely
to produce good results, and it might indeed generate the observed fault. 

For a further test, copying the libgnu/sigprocmask.c version of sigemptyset()
into sighandlers.cc (and renaming it) produces a compile-time error: 

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

sighandlers.cc: In function ‘int my_sigemptyset(sigset_t*)’:
sighandlers.cc:85: error: no match for ‘operator=’ in ‘* set = 0’
/usr/include/bits/sigset.h:31: note: candidates are: __sigset_t&
__sigset_t::operator=(const __sigset_t&)

also suggesting that the /usr/include version of sigset_t is not compatible
with the octave/libgnu version. 


(all this said, I can't explain how octave/libgnu can itself compile if
sigset_t is of incompatible type - I've tried to build a simple test case to
see if I can reproduce the observed segfault but it won't compile)


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?30685>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/