Re: sigprocmask.c appears to be incompatible w/ system headers
Hi Bruno,
Thank you for quick the response.
There is no sigprocmask.lo in this list. This is normal; gnulib's sigprocmask.c
is not compiled on glibc systems. You can see from the gnulib documentation
http://www.gnu.org/software/gnulib/manual/html_node/sigprocmask.html
that this source file is only compiled on mingw platforms.
Indeed. Placing an #error line in sigprocmask.cc did not disrupt the
build.
Also, the generated signal.h is built with HAVE_SIGSET_T being replaced with 1,
therefore it does not redefine the 'sigset_t' type.
Inhttps://savannah.gnu.org/bugs/?30685 you write:
A change (similar to Leonardo's) that seems to work while theoretically
maintaining sigaction
functionality is to explicitly call the sigemptyset macro (bits/sigset.h):
octave-3.4.0/src/sighandlers.cc line 225
//gnulib::sigemptyset (act.sa_mask);
//gnulib::sigemptyset (oact.sa_mask);
//gnulib::sigaction (sig,act,oact);
__sigemptyset (act.sa_mask);
__sigemptyset (oact.sa_mask);
sigaction (sig,act,oact);
(only removing the namespace didn't work for me either)
This indicates that the crucial difference is between the __sigemptyset
macro and the sigemptyset functions, both from glibc.
This report might be misleading, and there might not be a difference.
When I removed the gnulib namespace from the file entirely, and
recompiled, octave started and ran. The problem with this report was
that there were still some instances of gnulib:: on other function
calls. I suspect this was also the case when others removed gnulib on
sigemptyset and it still crashed (presumably on the subsequent
gnulib::sigaction).
Or if 'sigemptyset' would work fine, then the crucial difference would
be in the function pointer indirection by which gnulib implements the
'gnulib::sigemptyset' function in term of the 'sigemptyset' function
pointer.
In order to debug this, I would recommend to look at
- the source code of the __sigemptyset macro and of the sigemptyset
function,
From /usr/include/bits/sigset.h
# define _SIGSET_NWORDS (1024 / (8 * sizeof (unsigned long int)))
typedef struct
{
unsigned long int __val[_SIGSET_NWORDS];
} __sigset_t;
# define __sigemptyset(set) \
(__extension__ ({ int __cnt = _SIGSET_NWORDS; \
sigset_t *__set = (set); \
while (--__cnt = 0) __set-__val[__cnt] = 0; \
0; }))
I am unable to find source code for the sigemptyset function of glibc.
- the assembly level instructions where it crashes:
#0 0xb785896c in sigemptyset () from
/home/muttoni/a/octave-3.3.53/src/.libs/liboctinterp-3.3.53.so
because it's not clear why liboctinterp-3.3.53.so would contain
a sigemptyset function at all (since gnulib's one is not being
compiled).
This is naive speculation, but perhaps liboctinterp is involved because
gnulib::sigemptyset is being called, instead of simply sigemptyset?
As mentioned above, I removed all references of gnulib:: from the
problem file and recompiled, and it seemed to run fine. With the
namespace declared, it reliably crashes. Perhaps a link issue? This
speculation is discrepant with reports in the original octave bug, but
in those cases people (seem to have) only removed gnulib:: from
sigemptyset, leaving the other instances intact. If I do that, it does
crash.
Assembly instructions at breakpoint shortly before crash. Crash occurs
stepping past instruction at 0x2b630861baff.
Breakpoint 1, octave_set_signal_handler (sig=2,
handler=0x2b630861c080 sigint_handler, restart_syscalls=true)
at sighandlers.cc:206
206 act.sa_flags = 0;
2: x/10i $pc
0x2b630861bae3 _Z25octave_set_signal_handleriPFviEb+35:
---Type return to continue, or q return to quit---
movl $0x0,0x128(%rsp)
0x2b630861baee _Z25octave_set_signal_handleriPFviEb+46:
je 0x2b630861bb50 _Z25octave_set_signal_handleriPFviEb+144
0x2b630861baf0 _Z25octave_set_signal_handleriPFviEb+48:test %dl,%dl
0x2b630861baf2 _Z25octave_set_signal_handleriPFviEb+50:
je 0x2b630861baff _Z25octave_set_signal_handleriPFviEb+63
0x2b630861baf4 _Z25octave_set_signal_handleriPFviEb+52:
movl $0x1000,0x128(%rsp)
0x2b630861baff _Z25octave_set_signal_handleriPFviEb+63:
lea0xa0(%rsp),%r12
0x2b630861bb07 _Z25octave_set_signal_handleriPFviEb+71:
lea0x8(%r12),%rdi
0x2b630861bb0c _Z25octave_set_signal_handleriPFviEb+76:
callq 0x2b630905ede8 sigemptyset
0x2b630861bb11 _Z25octave_set_signal_handleriPFviEb+81:
lea0x8(%rsp),%rdi
0x2b630861bb16 _Z25octave_set_signal_handleriPFviEb+86:
callq 0x2b630905ede8 sigemptyset
1: x/3i $pc
0x2b630861bae3 _Z25octave_set_signal_handleriPFviEb+35:
movl $0x0,0x128(%rsp)
0x2b630861baee _Z25octave_set_signal_handleriPFviEb+46:
je 0x2b630861bb50 _Z25octave_set_signal_handleriPFviEb+144
---Type return to continue, or q return to quit---
0x2b630861baf0
Re: sigprocmask.c appears to be incompatible w/ system headers
Godfrey, Keith wrote: Program received signal SIGSEGV, Segmentation fault. 0x2b630905ede8 in sigemptyset () from /global/home/keith/software/octave-3.4.0/src/.libs/liboctinterp-3.4.0.so 2: x/10i $pc 0x2b630905ede8 sigemptyset: callq 0x2b636c0ef3da 0x2b630905eded sigemptyset+5: sub (%rax),%eax 0x2b630905edef sigemptyset+7: add %dh,%al 0x2b630905edf1 sigaction+1: in (%dx),%eax OK, so here you have an 8-byte area that defines a function 'sigemptyset' and whose code starts with a 'call' instruction? That must be the PLT (Procedure Linkage Table, [1]) in a state before the first 'sigemptyset' call. Where does the 0x2b636c0ef3da point to? Look at the /proc/pid/maps file of your process. When you have a SIGSEGV in the PLT, there are two possible causes: - Either a problem with the shared libraries (maybe caused by some linker options, maybe by a linker bug), - Or you have general memory corruption that happens to hit the PLT. For detecting this case, please run your application under valgrind. In either case, it's unrelated to gnulib. Please redirect followups to Octave list again, and omit bug-gnulib. Bruno [1] http://vxheavens.com/lib/vsc06.html -- In memoriam Diego de Enzinas http://en.wikipedia.org/wiki/Diego_de_Enzinas
sigprocmask.c appears to be incompatible w/ system headers
Greetings, I recently compiled octave on RedHat Enterprise 5.4 and it produced a segfault on startup. Investigation as to why suggests that there is an incompatibility between gnulib and the system headers. Specifically, sigset_t in /usr/include is a struct containing an array. However gnulib's sigprocmask.c looks to treat it as an integer, with the same prototype as defined in gnulib's signal.h. Octave crashes when calling the functions defined in sigprocmask.c (e.g., libgnu::sigemptyset() and libgnu::sigprocmask()), presumably because these functions are receiving a structure pointer instead of an int pointer. Commenting out the entirety of sigprocmask.c and recompiling (forcing calls to these functions to link w/ the system library) produces a stable octave build. I really don't understand these matters as this is my first interaction w/ both octave and gnulib, but the octave maintainer(s) suggest that this is a bug in gnulib. Their argument seems reasonable. octave bug: https://savannah.gnu.org/bugs/?30685 Thank you very much, and best regards, Keith
Re: sigprocmask.c appears to be incompatible w/ system headers
On 03/14/2011 12:15 AM, Keith Godfrey wrote: https://savannah.gnu.org/bugs/?30685 Apparently octave's configure script is incorrectly deciding that sigset_t does not work, and is therefore incorrectly setting HAVE_SIGSET_T to 0. Can you please investigate config.log and see why that is so?
Re: sigprocmask.c appears to be incompatible w/ system headers
On 03/14/2011 09:29 AM, Keith Godfrey wrote: Have sigset is set to 1. In that case, please investigate why libgnu/signal.h is behaving as if HAVE_SIGSET_T is 0. Try doing diff -u libgnu/signal.in.h libgnu/signal.h and looking for HAVE_SIGSET_T. And try removing libgnu/signal.h and then typing make, and see how signal.h is built.
Re: sigprocmask.c appears to be incompatible w/ system headers
Hi Paul, Output of the commands are attached, as is sigprocmask.c, in case it might be of assistance. HAVE_SIGSET_T is converted to '1', and make treats it as '1' as well. Best, Keith On 03/14/2011 12:25 PM, Paul Eggert wrote: On 03/14/2011 09:29 AM, Keith Godfrey wrote: Have sigset is set to 1. In that case, please investigate why libgnu/signal.h is behaving as if HAVE_SIGSET_T is 0. Try doing diff -u libgnu/signal.in.h libgnu/signal.h and looking for HAVE_SIGSET_T. And try removing libgnu/signal.h and then typing make, and see how signal.h is built. --- libgnu/signal.in.h 2011-02-08 03:03:19.0 -0700 +++ libgnu/signal.h 2011-03-11 22:30:27.0 -0700 @@ -1,3 +1,4 @@ +/* DO NOT EDIT! GENERATED AUTOMATICALLY! */ /* -*- buffer-read-only: t -*- vi: set ro: */ /* DO NOT EDIT! GENERATED AUTOMATICALLY! */ /* A GNU-like signal.h. @@ -18,14 +19,14 @@ along with this program. If not, see http://www.gnu.org/licenses/. */ #if __GNUC__ = 3 -@PRAGMA_SYSTEM_HEADER@ +#pragma GCC system_header #endif -@PRAGMA_COLUMNS@ + #if defined __need_sig_atomic_t || defined __need_sigset_t /* Special invocation convention inside glibc header files. */ -# @INCLUDE_NEXT@ @NEXT_SIGNAL_H@ +# include_next signal.h #else /* Normal invocation convention. */ @@ -33,16 +34,327 @@ #ifndef _GL_SIGNAL_H /* The include_next requires a split double-inclusion guard. */ -#@INCLUDE_NEXT@ @NEXT_SIGNAL_H@ +#include_next signal.h #ifndef _GL_SIGNAL_H #define _GL_SIGNAL_H /* The definitions of _GL_FUNCDECL_RPL etc. are copied here. */ +#ifndef _GL_CXXDEFS_H +#define _GL_CXXDEFS_H + +/* The three most frequent use cases of these macros are: + + * For providing a substitute for a function that is missing on some + platforms, but is declared and works fine on the platforms on which + it exists: + + #if @GNULIB_FOO@ + # if !@HAVE_FOO@ + _GL_FUNCDECL_SYS (foo, ...); + # endif + _GL_CXXALIAS_SYS (foo, ...); + _GL_CXXALIASWARN (foo); + #elif defined GNULIB_POSIXCHECK + ... + #endif + + * For providing a replacement for a function that exists on all platforms, + but is broken/insufficient and needs to be replaced on some platforms: + + #if @GNULIB_FOO@ + # if @REPLACE_FOO@ + # if !(defined __cplusplus defined GNULIB_NAMESPACE) + # undef foo + # define foo rpl_foo + # endif + _GL_FUNCDECL_RPL (foo, ...); + _GL_CXXALIAS_RPL (foo, ...); + # else + _GL_CXXALIAS_SYS (foo, ...); + # endif + _GL_CXXALIASWARN (foo); + #elif defined GNULIB_POSIXCHECK + ... + #endif + + * For providing a replacement for a function that exists on some platforms + but is broken/insufficient and needs to be replaced on some of them and + is additionally either missing or undeclared on some other platforms: + + #if @GNULIB_FOO@ + # if @REPLACE_FOO@ + # if !(defined __cplusplus defined GNULIB_NAMESPACE) + # undef foo + # define foo rpl_foo + # endif + _GL_FUNCDECL_RPL (foo, ...); + _GL_CXXALIAS_RPL (foo, ...); + # else + # if !@HAVE_FOO@ or if !@HAVE_DECL_FOO@ + _GL_FUNCDECL_SYS (foo, ...); + # endif + _GL_CXXALIAS_SYS (foo, ...); + # endif + _GL_CXXALIASWARN (foo); + #elif defined GNULIB_POSIXCHECK + ... + #endif +*/ + +/* _GL_EXTERN_C declaration; + performs the declaration with C linkage. */ +#if defined __cplusplus +# define _GL_EXTERN_C extern C +#else +# define _GL_EXTERN_C extern +#endif + +/* _GL_FUNCDECL_RPL (func, rettype, parameters_and_attributes); + declares a replacement function, named rpl_func, with the given prototype, + consisting of return type, parameters, and attributes. + Example: + _GL_FUNCDECL_RPL (open, int, (const char *filename, int flags, ...) + _GL_ARG_NONNULL ((1))); + */ +#define _GL_FUNCDECL_RPL(func,rettype,parameters_and_attributes) \ + _GL_FUNCDECL_RPL_1 (rpl_##func, rettype, parameters_and_attributes) +#define _GL_FUNCDECL_RPL_1(rpl_func,rettype,parameters_and_attributes) \ + _GL_EXTERN_C rettype rpl_func parameters_and_attributes + +/* _GL_FUNCDECL_SYS (func, rettype, parameters_and_attributes); + declares the system function, named func, with the given prototype, + consisting of return type, parameters, and attributes. + Example: + _GL_FUNCDECL_SYS (open, int, (const char *filename, int flags, ...) + _GL_ARG_NONNULL ((1))); + */ +#define _GL_FUNCDECL_SYS(func,rettype,parameters_and_attributes) \ + _GL_EXTERN_C rettype func parameters_and_attributes + +/* _GL_CXXALIAS_RPL (func, rettype, parameters); + declares a C++ alias called GNULIB_NAMESPACE::func + that redirects to rpl_func, if GNULIB_NAMESPACE is defined. + Example: + _GL_CXXALIAS_RPL (open, int, (const char *filename,
Re: sigprocmask.c appears to be incompatible w/ system headers
On 03/14/2011 05:46 AM, Godfrey, Keith wrote: HAVE_SIGSET_T is converted to '1', and make treats it as '1' as well. Thanks. Perhaps Bruno Haible can comment: he knows more about this issue. It appears to be a problem with older versions of GCC (4.1.2, say) when compiling C++, which I'm not expert in.
Re: sigprocmask.c appears to be incompatible w/ system headers
Godfrey, Keith wrote: Output of the commands are attached In make.txt you have this command: /bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -pthread -no-undefined -lm -lm -lm -lm -lm -L/global/home/keith/lib -o libgnu.la c-ctype.lo c-strcasecmp.lo c-strncasecmp.lo close-hook.lo exitfail.lo localcharset.lo malloca.lo openat-die.lo progname.lo sockets.lo strnlen1.lo asnprintf.lo basename-lgpl.lo chdir-long.lo cloexec.lo dirname-lgpl.lo dup-safer.lo fcntl.lo fd-safer.lo filemode.lo getcwd.lo getopt.lo getopt1.lo glob.lo md5.lo nanosleep.lo openat-proc.lo pipe-safer.lo printf-args.lo printf-parse.lo save-cwd.lo strftime.lo stripslash.lo tempname.lo vasnprintf.lo -lm There is no sigprocmask.lo in this list. This is normal; gnulib's sigprocmask.c is not compiled on glibc systems. You can see from the gnulib documentation http://www.gnu.org/software/gnulib/manual/html_node/sigprocmask.html that this source file is only compiled on mingw platforms. Also, the generated signal.h is built with HAVE_SIGSET_T being replaced with 1, therefore it does not redefine the 'sigset_t' type. In https://savannah.gnu.org/bugs/?30685 you write: A change (similar to Leonardo's) that seems to work while theoretically maintaining sigaction functionality is to explicitly call the sigemptyset macro (bits/sigset.h): octave-3.4.0/src/sighandlers.cc line 225 //gnulib::sigemptyset (act.sa_mask); //gnulib::sigemptyset (oact.sa_mask); //gnulib::sigaction (sig, act, oact); __sigemptyset (act.sa_mask); __sigemptyset (oact.sa_mask); sigaction (sig, act, oact); (only removing the namespace didn't work for me either) This indicates that the crucial difference is between the __sigemptyset macro and the sigemptyset functions, both from glibc. Or if 'sigemptyset' would work fine, then the crucial difference would be in the function pointer indirection by which gnulib implements the 'gnulib::sigemptyset' function in term of the 'sigemptyset' function pointer. In order to debug this, I would recommend to look at - the source code of the __sigemptyset macro and of the sigemptyset function, - the assembly level instructions where it crashes: #0 0xb785896c in sigemptyset () from /home/muttoni/a/octave-3.3.53/src/.libs/liboctinterp-3.3.53.so because it's not clear why liboctinterp-3.3.53.so would contain a sigemptyset function at all (since gnulib's one is not being compiled). - the preprocessed source file (g++ -E -dD) of the compilation unit that contains the gnulib::sigemptyset invocation. Bruno
