bugGNU Octave - Bugs: bug #30685, Segmentation fault in ./run-octave...

 
 

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

Submitted by:  Leo <muttoni>
Submitted on:  Sun 08 Aug 2010 02:13:28 PM UTC  
 
Category:  Interpreter Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Segfault, Bus Error, etc.
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  Closed
Release:  3.3.52 Operating System:  GNU/Linux

Add a New Comment (Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

( Jump to the original submission)

Fri 20 Mar 2015 09:22:23 AM UTC, comment #53: 

I am using octave 3.8.2 and while running it i am getting segmentation fault error.

while debugging i found:

Program received signal SIGSEGV, Segmentation fault.
0x00002aaaac4ec078 in sigemptyset () from /home/vishal/octave/octave_install/lib/octave/3.8.2/liboctinterp.so.2

i am compiling it with latest intel compilers .

i have read that it was bug in older version . but i am facing this problem in latest version.
thanks in advance

vishal <vishalb>
Thu 16 Feb 2012 04:33:06 PM UTC, comment #52: 

OK, the change I made will be part of Octave 3.6.1 so I'm closing this report.

John W. Eaton <jwe>
Project Administrator
Thu 16 Feb 2012 03:51:42 PM UTC, comment #51: 

After applying the change in

http://hg.savannah.gnu.org/hgweb/octave/rev/1ecfba4427ff

I was able to build and run octave-3.6.0 on CentOS 5 with the patch applied. Without the patch, octave builds but crashes with segmentation violation.

Kent Engström <kent>
Mon 06 Feb 2012 08:29:16 PM UTC, comment #50: 

I checked in my change here:

http://hg.savannah.gnu.org/hgweb/octave/rev/1ecfba4427ff

It would be helpful if someone could tell me whether this change actually does avoid the problem.  If it does, then I'll close this report.

John W. Eaton <jwe>
Project Administrator
Sat 04 Feb 2012 07:41:33 PM UTC, comment #49: 

John,

This looks like it has a good chance of working,
but I cannot get access to gcc 4.2.1 system for
about 2 weeks.  If no one else has done the testing,
I will do it then.

Michael Godfrey <godfrey>
Project Member
Sat 04 Feb 2012 05:04:52 PM UTC, comment #48: 

Does the attached patch avoid the problem?

(file #24978)

John W. Eaton <jwe>
Project Administrator
Fri 20 Jan 2012 05:51:17 PM UTC, comment #47: 

Note: bug 33927 is listed as a duplicate of this.

Since Redhat 5 uses gcc 4.1 this bug prevents installing
octave 3.6 on these Redhat systems.  Many users are
still on Redhat 5

Therefore, this should be marked as a bug in 3.6, and
it would help if someone familiar with the initialization
code could take a look.  The diagnositc information below
seems fairly complete.  I currently only have access to
RHEL 5 systems about once a week, but I can try to work on
this if possible.

Michael

Michael Godfrey <godfrey>
Project Member
Sat 19 Nov 2011 02:55:22 AM UTC, comment #46: 

I'm seeing this same issue with octave-3.4.3 on powerpc-apple-darwin8 built with XCode-2.5 (g++-4.0.1, build 5370)

http://paste.lisp.org/display/125952#4

I found the sigemptyset symbol here (with nm):
src/.libs/liboctinterp.dylib(liboctinterp.0.dylib-master.o):
...

00f00390 d _sigaction
00f0039c d _sigaddset
00f00394 d _sigemptyset

Will try to debug this with the suggestions here.

David Fang <fangism>
Sun 18 Sep 2011 02:05:55 AM UTC, comment #45: 

Its been more than a year since the last comment. Is this still an active problem?

The default, stable branches each compie on MacOS using the Applified gcc 4.2.1.

Perhaps this should be closed?

Ben Abbott <bpabbott>
Project Member
Fri 08 Apr 2011 10:07:38 PM UTC, comment #44: 

Another data point, strongly suggesting a gcc bug.

I was seeing similar problems (segfault in sigemptyset) on
x86_64 running 64 bit RHEL 5.5, after a successful build on RHEL 6.0 system.

It does look like is a compiler issue:
the segfault occured when compiling with gcc 4.2.1, which although
later than the 4.1.2 most people posting were using, is admittedly
old.

Recompiled on the same platform, with same options using gcc 4.4.3
and the issue went away.

Tom Payerle <payerle>
Fri 18 Mar 2011 04:54:27 AM UTC, comment #43: 

There is only gcc 4.1.2 on the server (cluster) in question, and it's not realistic to install another version. Octave compiles and runs fine on my personal machine (debian, gcc 4.4.5).

Perhaps a link issue? It's certainly confusing as everything appears correct.

I understand that it's not an option to remove "gnulib::" from the master source tree. However, would it be a safe/stable solution to remove it in builds where it does cause problems (ie, should such a build be as functional/stable as the normal packaged releases)?

Keith Godfrey <aquilonis>
Fri 18 Mar 2011 02:19:18 AM UTC, comment #42: 

In the sighandlers.ii file you uploaded, I see the following:

...

# 213 "/usr/include/signal.h" 2 3 4

...

extern int sigemptyset (sigset_t *__set) throw () __attribute__ ((__nonnull__ (1)));

...

# 441 "../libgnu/signal.h" 3
namespace gnulib { static int (*sigemptyset) (sigset_t *set) = ::sigemptyset; } extern "C" int _gl_cxxalias_dummy;

...

sig_handler *
octave_set_signal_handler (int sig, sig_handler *handler,
                           bool restart_syscalls)
{
  struct sigaction act, oact;

  act.__sigaction_handler.sa_handler = handler;
  act.sa_flags = 0;


  if (sig == 14)
    {

      act.sa_flags |= 0x20000000;

    }



  else


  if (restart_syscalls)
    act.sa_flags |= 0x10000000;


  gnulib::sigemptyset (&act.sa_mask);
  gnulib::sigemptyset (&oact.sa_mask);
  gnulib::sigaction (sig, &act, &oact);

  return oact.__sigaction_handler.sa_handler;
}

...

so it looks to me like sigemptyset is declared in the system signal.h file, then a function pointer that refers to it is created in the gnulib namespace, then that is used in the octave_set_signal_handler function.  I don't see anything wrong with this code.

I see that you are using GCC 4.1.2.  Does this problem happen with other versions of GCC on your system, or only with GCC 4.1.2?

John W. Eaton <jwe>
Project Administrator
Thu 17 Mar 2011 03:59:41 AM UTC, comment #41: 

Sorry about that - here's the output again:

liboctinterp_la-sighandlers.o
0000000000000000 d sigemptyset

sighandlers.ii.bz2 attached

(file #22942)

Keith Godfrey <aquilonis>
Wed 16 Mar 2011 10:06:07 PM UTC, comment #40: 

It looks like your comment was maybe mangled by the rich markup feature of the bug tracker text boxes.  Please use the verbatim tags for code and other bits of text that should be quoted verbatim.

In any case, I'm not much closer to understanding what is happening here.

Can you please add -save-temps to the compiler flags used to compile sighandlers.cc and attach the resulting .ii file here?  I've already requested that in the past, but the one posted previously may not match yours, and it certainly doesn't give me any clue about how sigemptyset could be defined in sighandlers.cc and also have an address of 0.

John W. Eaton <jwe>
Project Administrator
Wed 16 Mar 2011 08:16:57 PM UTC, comment #39: 

It's indeed different. I get a single result running the script, and a NULL at that:

liboctinterp_la-sighandlers.o

                                1. d sigemptyset
Keith Godfrey <aquilonis>
Wed 16 Mar 2011 07:48:52 PM UTC, comment #38: 

OK, then try this in your build tree:

cd src/.libs
for f in *.o; do
  if $(nm $f | grep sigemptyset > /dev/null); then
    echo $f;
    nm $f | grep sigemptyset;
  fi;
done

and attach the output here.

In every object file that I have in src/.libs and that includes a sigemptyset symbol, I see the same result:

0000000000000218 d _ZN6gnulibL11sigemptysetE
                 U sigemptyset

So on my system I only see the gnulib::sigemptyset pointer that references the system sigemptyset function.  I'm guessing this result will be different on your system.

John W. Eaton <jwe>
Project Administrator
Wed 16 Mar 2011 07:22:54 PM UTC, comment #37: 

> If there is a function called sigemptyset which
> is defined in liboctinterp, then where is it
> coming from?


A very good question...
I've looked at the make output and have no clues either.

> (gdb) ptype sigset_t


Program received signal SIGSEGV, Segmentation fault.
0x00002b74012f4de8 in sigemptyset ()
   from /global/home/keith/software/octave-3.4.0/src/.libs/liboctinterp-3.4.0.so
(gdb) ptype sigset_t
type = struct ._6 {
    long unsigned int __val[16];
}

Same result in octave_set_signal_handler.

Keith Godfrey <aquilonis>
Wed 16 Mar 2011 07:10:48 PM UTC, comment #36: 

If there is a function called sigemptyset which is defined in liboctinterp, then where is it coming from?  I don't see any function called sigemptyset defined in any file in the Octave sources except the one from gnulib.

What does

(gdb) ptype sigset_t

say the type of sigset_t is in the scope of the octave_set_signal_handler function?  What about in the sigemptyset function?

John W. Eaton <jwe>
Project Administrator
Wed 16 Mar 2011 06:26:44 PM UTC, comment #35: 

The only breakpoint I can set is in octave_set_signal_handler as the code from libgnu/sigprocmask.c is not compiled. Stepping into the linked version of sigemptyset at the assembly level, and typing "where" generates the stack trace below. The subsequent stepi crashes.

(gdb)
0x00002af563822de8 in sigemptyset ()
   from /global/home/keith/software/octave-3.4.0/src/.libs/liboctinterp-3.4.0.so
1: x/3i $pc
0x2af563822de8 <sigemptyset>: callq  0x2af558e5b01a
0x2af563822ded <sigemptyset+5>: sub    (%rax),%al
0x2af563822def <sigemptyset+7>: add    %dh,%al
(gdb) where
#0  0x00002af563822de8 in sigemptyset ()
   from /global/home/keith/software/octave-3.4.0/src/.libs/liboctinterp-3.4.0.so
#1  0x00002af562ddfb11 in octave_set_signal_handler (sig=2,
    handler=0x2af562de0080 <sigint_handler>, restart_syscalls=true)
    at sighandlers.cc:233
#2  0x00002af562ddfbda in octave_catch_interrupts () at sighandlers.cc:467
#3  0x00002af562ddfc43 in install_signal_handlers () at sighandlers.cc:536
#4  0x00002af562db2577 in octave_main (argc=6, argv=0x7fffca36c0b8, embedded=0)
    at octave.cc:665
#5  0x0000003cc421d994 in __libc_start_main () from /lib64/libc.so.6
#6  0x00000000004006a9 in _start ()
(gdb)

excerpt from 'nm liboctinterp-3.4.0.so' :

0000000001009df0 d sigaction
0000000001009df8 d sigaddset
0000000001009de8 d sigemptyset
0000000001009e00 d sigprocmask

I don't know if this might be helpful, or simply add noise as I'm way outside of my element here, but the instruction at the address of sigemptyset are not consistent between runs. The 3 instructions associated with sigemptyset seem to be, but not after. Also, these instructions don't appear to be consistent with function calls - e.g., no returns

0x2ae09f511de8 <sigemptyset>: callq  0x2ae07ff06f0a
0x2ae09f511ded <sigemptyset+5>: sub    (%rax),%al
0x2ae09f511def <sigemptyset+7>: add    %dh,%al
0x2ae09f511df1 <sigaction+1>: sbb    $0x2ae09f51,%eax
0x2ae09f511df6 <sigaction+6>: add    %al,(%rax)
0x2ae09f511df8 <sigaddset>: clc   

0x2b9236b10de8 <sigemptyset>: callq  0x2b91c8e7befa
0x2b9236b10ded <sigemptyset+5>: sub    (%rax),%eax
0x2b9236b10def <sigemptyset+7>: add    %dh,%al
0x2b9236b10df1 <sigaction+1>: or     $0x2b9236b1,%eax
0x2b9236b10df6 <sigaction+6>: add    %al,(%rax)
0x2b9236b10df8 <sigaddset>: clc   

0x2b93c0259de8 <sigemptyset>: callq  0x2b9353e5c38a
0x2b93c0259ded <sigemptyset+5>: sub    (%rax),%eax
0x2b93c0259def <sigemptyset+7>: add    %dh,%al
0x2b93c0259df1 <sigaction+1>: popfq 
0x2b93c0259df2 <sigaction+2>: and    $0x2b93c0,%eax
0x2b93c0259df7 <sigaction+7>: add    %bh,%al
0x2b93c0259df9 <sigaddset+1>: popfq 

Keith Godfrey <aquilonis>
Wed 16 Mar 2011 02:42:52 PM UTC, comment #34: 

I won't remove teh gnulib:: tags from the calls to sigemptyset, because presumably they are needed on some systems.

To debug this, let's start by trying to find the location of the definition of the sigemptyset function that is showing up in liboctinterp.

One way I can think of to do that is to compile a copy of Octave that is not modified to remove the gnulib:: tags from the sigemptyset calls, run it under gdb, set a breakpoint in the sigemptyset function and the use "where" to find out where that function definition is actually coming from.

Maybe it would also be possible by looking at the output of

nm liboctinterp-3.4.0.so

John W. Eaton <jwe>
Project Administrator
Tue 15 Mar 2011 07:37:46 PM UTC, comment #33: 

A discussion w/ the kind folks at gnulib provided information, but no resolution. They pointed out that gnulib/sigprocmask.c is not compiled (grep-ing the make output confirmed this, as did an '#error' statement inserted there before a fresh build). It seems to be a link error.

The apparent resolution (hack) to get octave to compile/run is to simply remove all instances of "gnulib::" from sighandlers.cc.

Summary of discussion w/ gnulib below. It starts with an assembly trace of where the sigfault occurred.

------------

> Program received signal SIGSEGV, Segmentation fault.
> 0x00002b630905ede8 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.

[1] http://vxheavens.com/lib/vsc06.html

<< KG NOTE: the call address in sigemptyset is not in a memory range specified in proc/<pid>/maps. This address sits after the last shared object. The address of sigemptyset itself points to liboctinterp-3.4.0.so, so I should be looking at the correct map >>

Keith Godfrey <aquilonis>
Mon 14 Mar 2011 07:21:13 AM UTC, comment #32: 

my bad. I've filed a bug w/ gnulib.

Keith Godfrey <aquilonis>
Sat 12 Mar 2011 06:36:34 PM UTC, comment #31: 

I think you are misunderstanding how gnulib is supposed to work.

By using the gnulib module that provides the wrapper for sigemptyset, it should automatically replace sigemptyset if it is missing or broken, and just make gnulib::sigemptyset a call to the system function otherwise.  So our code doesn't have to change, it call always call gnulib::sigemptyset.

That this apparently doesn't work properly on some systems indicates a bug in gnulib.

John W. Eaton <jwe>
Project Administrator
Sat 12 Mar 2011 06:20:31 PM UTC, comment #30: 

I'd guess that gnulib is behaving properly - it provides a standard API w/ basic functionality (eg., 32 signal handlers instead of 1024 under current debian/fedora) in a small and portable code base that can substitute when equivalent OS-level calls aren't present. Gnulib data structures won't necessarily be compatible w/ the OS versions, if the later are even present.

The problem would seem to be that the octave configuration system is allowing calls to both gnulib and the OS libs (and headers). When adequate OS libs are present, they should be used exclusively. When not, the gnulibs should be called. Alternatively, always use the GNU libs and headers. The problem comes when mixing the two.

On that note, I'd think that this bug should be re-targeted internally as a configuration (or make) bug.

As a workaround for those wishing to compile from scratch, putting an '#ifdef NEVER' / #endif pair around the entirety of gnulib/sigprocmask.c, removing all 'gnulib::' from src/sighandlers.cc, and recompiling seemed to produce a stable build, for as much as I've been able to test it at least.

Keith Godfrey <aquilonis>
Sat 12 Mar 2011 02:22:34 PM UTC, comment #29: 

Yes, the problem is likely due to an incompatibility between the gnulib function and the definition of the sigset_t type.

This is most likely a bug in gnulib.

By some configure magic, it should ensure that these functions are only used on systems where they are needed, and it should ensure that the functions match the declarations of things like sigset_t.

Maybe it would help to report the problem to the gnulib maintainers?

John W. Eaton <jwe>
Project Administrator
Sat 12 Mar 2011 05:32:31 AM UTC, comment #28: 

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)

Keith Godfrey <aquilonis>
Fri 11 Mar 2011 08:56:47 PM UTC, comment #27: 

Compiling octave 3.4.0 on Redhat Enterprise 5.4, gcc 4.1.2, results in same problem (segmentation fault when calling run-octave).

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)

Keith Godfrey <aquilonis>
Thu 24 Feb 2011 08:01:12 PM UTC, comment #26: 

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.

John W. Eaton <jwe>
Project Administrator
Thu 24 Feb 2011 06:51:37 PM UTC, comment #25: 

gcc44-c++-4.4.4-13.el5--same bug
Program received signal SIGSEGV, Segmentation fault.
0x00002aaaabaf4248 in sigemptyset ()
   from /home/sfw/lib/octave-3.4.0/liboctinterp-3.4.0.so

Anonymous
Wed 23 Feb 2011 01:55:26 AM UTC, comment #24: 

Octave 3.4.0 works for me on OSX 10.6.6 (XCode 3.2.3), using MacPorts' GCC 4.4.5 (not Apple's GCC 4.1.2).

Michael Dickens <michaelld>
Tue 22 Feb 2011 11:40:15 PM UTC, comment #23: 

From my original post:

  • Slackware 12.1 (32 bit) updated with the latest distro packages * Gcc 4.2.3

Thanks,

Leo.

Leo <muttoni>
Tue 22 Feb 2011 08:36:34 PM UTC, comment #22: 

Can anyone reproduce the problem using a current GCC release?  By current, I mean either GCC 4.5.2, 4.4.5, or 4.3.5, which are the latest versions of each release series that are currently supported.

Is everyone who has this problem using GCC 4.1.2?

John W. Eaton <jwe>
Project Administrator
Tue 22 Feb 2011 08:29:11 PM UTC, comment #21: 

Hi Leonardo,

> This problem still occurs only with me?


No, I have exactly the same problem with octave 3.4.0:

Program received signal SIGSEGV, Segmentation fault.
0x00002aaaabb14508 in sigemptyset () from /u/mc/Download/new/octave-3.4.0/src/.libs/liboctinterp-3.4.0.so
(gdb) where
#0  0x00002aaaabb14508 in sigemptyset () from /u/mc/Download/new/octave-3.4.0/src/.libs/liboctinterp-3.4.0.so

I'm using gcc 4.1.2 on Scientific Linux SL release 5.5. It might be an issue with the gcc version. I tried octave 3.4.0, on a more recent machine (gcc 4.4.3) without a problem.

Best regards,
Alex

Alexander Barth <abarth>
Sun 20 Feb 2011 10:00:45 PM UTC, comment #20: 

Hello!

For me, the new stable release of Octave (3.4.0) have the same issues...

(...)
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb34ef990 (LWP 25801)]
0xb77a85ec in sigemptyset () from /home/muttoni/octave-3.4.0/src/.libs/liboctinterp-3.4.0.so

This problem still occurs only with me?

Best regards,

Leonardo.

Leo <muttoni>
Sun 06 Feb 2011 06:58:17 PM UTC, comment #19: 

In MacPorts, I've updated octave-devel to 3.3.91, and we no longer have this issue.  There are -other- issues to deal with, but those are now runtime & I believe there are already tickets open for them.  So, from my perspective, this ticket can be closed.  Others?

Michael Dickens <michaelld>
Wed 27 Oct 2010 12:22:55 AM UTC, comment #18: 

After cleaning the room, I did step by step:

1> export CFLAGS="-ggdb3"; export CXXFLAGS=$CFLAGS; unset LDFLAGS
2> ./configure --prefix=/usr
3> make -j2
4> [I edited 'src/Makefile', line 6141 (added the '-save-temps') ]:

6140: liboctinterp_la-sighandlers.lo: sighandlers.cc
6141:        $(LIBTOOL)  --tag=CXX $(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=compile $(CXX) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(liboctinterp_la_CPPFLAGS) $(CPPFLAGS) $(AM_CXXFLAGS) -save-temps $(CXXFLAGS) -MT liboctinterp_la-sighandlers.lo -MD -MP -MF $(DEPDIR)/liboctinterp_la-sighandlers.Tpo -c -o liboctinterp_la-sighandlers.lo `test -f 'sighandlers.cc' || echo '$(srcdir)/'`sighandlers.cc
6142:        $(am__mv) $(DEPDIR)/liboctinterp_la-sighandlers.Tpo $(DEPDIR)/liboctinterp_la-sighandlers.Plo

And I erased the related files to force the recompilation with the new flag:

5> rm src/.libs/liboctinterp_la-sighandlers.o
6> rm src/liboctinterp_la-sighandlers.lo
7> make -j2
8> ./run-octave -g

(see attached file "gdb_runs.tar.gz" for the result of running './run-octave -g' eigth times. I made this because I've noted that, strangely, each run produced a different result).

See Files attached:

1) libgnu__signal.h.gz (libgnu/signal.h)
2) config.log.gz (config.log)
3) config.h.gz (config.h)
4) src__sighandlers.ii.gz (src/sighandlers.ii)

My hardware is a core 2 duo. For my gcc version (4.2.3), the flag "-march=nocona" is the way to do optimization.

(file #21834, file #21835, file #21836, file #21837)

Leo <muttoni>
Tue 26 Oct 2010 01:03:39 AM UTC, comment #17: 

Please attach copies of the following files to the bug report:

  libgnu/signal.h
  config.log
  config.h

BTW, why are you compiling with -march=nocona?  What hardware do you have?

Also, can you please try with just CXXFLAGS and CFLAGS set to -ggdb3 and no optimization or special architecture options?

It might also be useful to see the preprocessed source file for sighandlers.cc.  Add -save-temps to the command used to compile that file and attach the resulting sighandlers.ii file.

John W. Eaton <jwe>
Project Administrator
Tue 26 Oct 2010 12:28:21 AM UTC, comment #16: 

After cleaning the building tree, I've changed my enviromental variables:

> export CFLAGS="$CFLAGS -g"; export CXXFLAGS=$CFLAGS


Wich turned these variables to "-march=nocona -O3 -g".

Then, I "./configure --prefix=/usr", "make -j3", and run "./run-octave -g":

> ./run-octave -g
(gdb) run
(...)
[Thread debugging using libthread_db enabled]
[New Thread 0xb3762940 (LWP 13891)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb3762940 (LWP 13891)]
0xb785896c in sigemptyset () from /home/muttoni/a/octave-3.3.53/src/.libs/liboctinterp-3.3.53.so

(gdb) bt full
#0  0xb785896c in sigemptyset () from /home/muttoni/a/octave-3.3.53/src/.libs/liboctinterp-3.3.53.so
No symbol table info available.
#1  0xb6fc3370 in octave_set_signal_handler (sig=2, handler=0xb6fc3e32 <sigint_handler>, restart_syscalls=true) at sighandlers.cc:198
        act = {__sigaction_handler = {sa_handler = 0xb6fc3e32 <sigint_handler>, sa_sigaction = 0xb6fc3e32 <sigint_handler>}, sa_mask = {__val = {3035721716, 3035726112,
      136868752, 3219033752, 3034833776, 3035726112, 136868752, 136879920, 3064499892, 3079140120, 136868744, 24058386, 3079266292, 3064499892, 3079140120, 3219033808,
      3079206457, 3079140560, 0, 1, 1, 0, 3064993099, 2388, 3064324096, 14762624, 1, 3064499892, 3079082020, 3219033896, 0, 3219033864}}, sa_flags = 268435456,
  sa_restorer = 0xb787cd20 <octave_signals_caught>}
        oact = {__sigaction_handler = {sa_handler = 0xbfde8e80, sa_sigaction = 0xbfde8e80}, sa_mask = {__val = {1, 3079140560, 3219033796, 3219033824, 3219033792,
      3079140120, 3064993099, 3219033760, 1, 0, 875724625, 0, 0, 3079140120, 3064983407, 136793860, 3219033640, 3034349556, 3534266940, 0, 0, 3035619296, 75, 3035721716,
      3219033872, 3079140120, 3064983165, 3034833776, 3035726112, 136879920, 3782204605, 0}}, sa_flags = 0, sa_restorer = 0x8289f28}
#2  0xb6fc342e in octave_catch_interrupts () at sighandlers.cc:474
        retval = {int_handler = 0xb4f18150 <main_arena+48>}
#3  0xb6fc34fa in install_signal_handlers () at sighandlers.cc:543
No locals.
#4  0xb6f8caf0 in octave_main (argc=6, argv=0xbfde9134, embedded=0) at octave.cc:624
        forced_line_editing = <value optimized out>
        read_history_file = <value optimized out>
        last_arg_idx = <value optimized out>
        remaining_args = <value optimized out>
        retval = <value optimized out>
#5  0x0804866e in ?? ()
No symbol table info available.
#6  0x00000006 in ?? ()
No symbol table info available.
#7  0xbfde9134 in ?? ()
No symbol table info available.
#8  0x00000000 in ?? ()
No symbol table info available.
(gdb)

I'm a beginner in debugging. Please tell me any additional GDB commands that I must run.

After build:

> ls libgnu/.libs/s*

libgnu/.libs/save-cwd.o  libgnu/.libs/sockets.o  libgnu/.libs/strftime.o  libgnu/.libs/stripslash.o  libgnu/.libs/strnlen1.o

There is no "sigprocmask.o" here.

Another broader try:

> find -iname "sigprocmask*"

./libgnu/.deps/sigprocmask.Plo
./libgnu/sigprocmask.c

What is the next step?

Leo <muttoni>
Sat 23 Oct 2010 04:02:13 PM UTC, comment #15: 

When you build Octave, does a copy of sigprocmask.c appear in the libgnu directory of your build tree?  If so, and it is compiled, can you please run nm on the resulting .o file and attach the output?  It should be in libgnu/.libs/sigprocmask.o.  Given the contents of your config.log file, I don't see why this file should be compiled, but if it is, I imagine that it could cause trouble for you.  Looking at the configure script, it seems that sigprocmask.c should only be added to the list of gnulib files to compile if HAVE_POSIX_SIGNALBLOCKING=0, but your config.log shows that variable set to 1, not 0.

John W. Eaton <jwe>
Project Administrator
Sat 23 Oct 2010 03:35:01 PM UTC, comment #14: 

Could you please also try compiling with -g so we can get some more useful information form the debugger?  Just having a stack trace is not sufficient for me here.  I need to see precisely where the crash occurred, and values of variables around the crash.
Precisely which variable access caused the signal, and why?

John W. Eaton <jwe>
Project Administrator
Sat 23 Oct 2010 11:59:20 AM UTC, comment #13: 

ok.

See attached config.log.

Backtrace follows:

--------- bt start ---------
[AFTER RUNNING ./run-octave -g, typing 'run', pressing enter twice (and getting a SIGSEGV), I typed:]

(gdb) bt
#0  0xb77731ec in sigemptyset () from /home/muttoni/a/octave-3.3.53/src/.libs/liboctinterp-3.3.53.so
#1  0xb6eddcb0 in octave_set_signal_handler ()
   from /home/muttoni/a/octave-3.3.53/src/.libs/liboctinterp-3.3.53.so
#2  0xb6eddd6e in octave_catch_interrupts ()
   from /home/muttoni/a/octave-3.3.53/src/.libs/liboctinterp-3.3.53.so
#3  0xb6edde3a in install_signal_handlers ()
   from /home/muttoni/a/octave-3.3.53/src/.libs/liboctinterp-3.3.53.so
#4  0xb6ea7430 in octave_main () from /home/muttoni/a/octave-3.3.53/src/.libs/liboctinterp-3.3.53.so
#5  0x080486be in ?? ()
#6  0x00000006 in ?? ()
#7  0xbf8f73a4 in ?? ()
#8  0x00000000 in ?? ()

--------- end ---------

Leo <muttoni>
Sat 23 Oct 2010 04:36:00 AM UTC, comment #12: 

Also, maybe you could attach your config.log file so I can see the results of the configure tests related to signal handling.

John W. Eaton <jwe>
Project Administrator
Sat 23 Oct 2010 04:20:28 AM UTC, comment #11: 

To start, you could get a backtrace from gdb to see precisely where it crashes.

John W. Eaton <jwe>
Project Administrator
Fri 22 Oct 2010 10:49:12 PM UTC, comment #10: 

Pong!

The same bug persists :(

Running "./run-octave -g" gives again:
(...)
(gdb) run
(...)
---Type <return> to continue, or q <return> to quit---
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0xb35dd940 (LWP 5718)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb35dd940 (LWP 5718)]
0xb76d11ec in sigemptyset () from /home/muttoni/a/octave-3.3.53/src/.libs/liboctinterp-3.3.53.so
(gdb)

What can we do?

Leo <muttoni>
Fri 22 Oct 2010 05:00:31 PM UTC, comment #9: 

Ping.

Is this problem still happening with the 3.3.53 snapshot?

John W. Eaton <jwe>
Project Administrator
Tue 14 Sep 2010 04:46:02 PM UTC, comment #8: 

Since this looks like a gnulib problem, could you try again with the development sources and make sure that when you run autogen.sh, you get the latest version of gnulib from git?  If the problem remains, then we can discuss with the gnulib maintainers.

Or, you can wait for the next snapshot which will have whatever is current in gnulib at the time I make the snapshot and so might also fix the problem.

John W. Eaton <jwe>
Project Administrator
Tue 14 Sep 2010 02:54:26 PM UTC, comment #7: 

Hi,

I'm working on a centos intel xeon workstation and I get the same errors as muttoni.

------------------------------
Software versions / settings:
------------------------------
Linux version 2.6.18-128.7.1.el5 (mockbuild@builder10.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-44)) #1 SMP Mon Aug 24 08:21:56 EDT 2009

configure command:

./configure --prefix=/home/gplms/soft/octave3.3 --with-blas=/usr/lib64/atlas/libf77blas.so.3.0 --with-lapack=/usr/lib64/atlas/liblapack.so.3.0 --with-atlas=/usr/lib64/atlas/libatlas.so.3.0 --without-curl --enable-docs=no 2>&1 | tee c.txt

make command:

make -j5 2>&1 | tee m.txt

As muttoni my compilation succeeded and executing octave or ./run-octave leeds to:
segmentation fault

./run-octave -g   outputs:

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>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...
(gdb) run
Starting program: /home/gplms/download/octave-3.3.52/src/.libs/lt-octave --no-init-path --path=/home/gplms/download/octave-3.3.52/test:/home/gplms/download/octave-3.3.52/scripts:/home/gplms/download/octave-3.3.52/scripts/image:/home/gplms/download/octave-3.3.52/scripts/linear-algebra:/home/gplms/download/octave-3.3.52/scripts/time:/home/gplms/download/octave-3.3.52/scripts/startup:/home/gplms/download/octave-3.3.52/scripts/general:/home/gplms/download/octave-3.3.52/scripts/set:/home/gplms/download/octave-3.3.52/scripts/specfun:/home/gplms/download/octave-3.3.52/scripts/elfun:/home/gplms/download/octave-3.3.52/scripts/io:/home/gplms/download/octave-3.3.52/scripts/miscellaneous:/home/gplms/download/octave-3.3.52/scripts/testfun:/home/gplms/download/octave-3.3.52/scripts/polynomial:/home/gplms/download/octave-3.3.52/scripts/sparse:/home/gplms/download/octave-3.3.52/scripts/geometry:/home/gplms/download/octave-3.3.52/scripts/optimization:/home/gplms/download/octave-3.3.52/scripts/pkg:/home/gplms/download/octave-3.3.52/scripts/special-matrix:/home/gplms/download/octave-3.3.52/scripts/strings:/home/gplms/download/octave-3.3.52/scripts/audio:/home/gplms/download/octave-3.3.52/scripts/signal:/home/gplms/download/octave-3.3.52/scripts/path:/home/gplms/download/octave-3.3.52/scripts/statistics:/home/gplms/download/octave-3.3.52/scripts/statistics/base:/home/gplms/download/octave-3.3.52/scripts/statistics/distributions:/home/gplms/download/octave-3.3.52/scripts/statistics/tests:/home/gplms/download/octave-3.3.52/scripts/statistics/models:/home/gplms/download/octave-3.3.52/scripts/help:/home/gplms/download/octave-3.3.52/scripts/plot:/home/gplms/download/octave-3.3.52/scripts/deprecated:/home/gplms/download/octave-3.3.52/scripts/.deps:/home/gplms/download/octave-3.3.52/scripts/.libs:/home/gplms/download/octave-3.3.52/scripts:/home/gplms/download/octave-3.3.52/scripts/image:/home/gplms/download/octave-3.3.52/scripts/linear-algebra:/home/gplms/download/octave-3.3.52/scripts/time:/home/gplms/download/octave-3.3.52/scripts/startup:/home/gplms/download/octave-3.3.52/scripts/general:/home/gplms/download/octave-3.3.52/scripts/set:/home/gplms/download/octave-3.3.52/scripts/specfun:/home/gplms/download/octave-3.3.52/scripts/elfun:/home/gplms/download/octave-3.3.52/scripts/io:/home/gplms/download/octave-3.3.52/scripts/miscellaneous:/home/gplms/download/octave-3.3.52/scripts/testfun:/home/gplms/download/octave-3.3.52/scripts/polynomial:/home/gplms/download/octave-3.3.52/scripts/sparse:/home/gplms/download/octave-3.3.52/scripts/geometry:/home/gplms/download/octave-3.3.52/scripts/optimization:/home/gplms/download/octave-3.3.52/scripts/pkg:/home/gplms/download/octave-3.3.52/scripts/special-matrix:/home/gplms/download/octave-3.3.52/scripts/strings:/home/gplms/download/octave-3.3.52/scripts/audio:/home/gplms/download/octave-3.3.52/scripts/signal:/home/gplms/download/octave-3.3.52/scripts/path:/home/gplms/download/octave-3.3.52/scripts/statistics:/home/gplms/download/octave-3.3.52/scripts/statistics/base:/home/gplms/download/octave-3.3.52/scripts/statistics/distributions:/home/gplms/download/octave-3.3.52/scripts/statistics/tests:/home/gplms/download/octave-3.3.52/scripts/statistics/models:/home/gplms/download/octave-3.3.52/scripts/help:/home/gplms/download/octave-3.3.52/scripts/plot:/home/gplms/download/octave-3.3.52/scripts/deprecated:/home/gplms/download/octave-3.3.52/scripts/.deps:/home/gplms/download/octave-3.3.52/scripts/.libs:/home/gplms/download/octave-3.3.52/src:/home/gplms/download/octave-3.3.52/src/TEMPLATE-INST:/home/gplms/download/octave-3.3.52/src/TEMPLATE-INST/.deps:/home/gplms/download/octave-3.3.52/src/TEMPLATE-INST/.libs:/home/gplms/download/octave-3.3.52/src/DLD-FUNCTIONS:/home/gplms/download/octave-3.3.52/src/DLD-FUNCTIONS/.deps:/home/gplms/download/octave-3.3.52/src/DLD-FUNCTIONS/.libs:/home/gplms/download/octave-3.3.52/src/OPERATORS:/home/gplms/download/octave-3.3.52/src/OPERATORS/.deps:/home/gplms/download/octave-3.3.52/src/OPERATORS/.libs:/home/gplms/download/octave-3.3.52/src/.deps:/home/gplms/download/octave-3.3.52/src/.libs --image-path=/home/gplms/download/octave-3.3.52/scripts/image --doc-cache-file=/home/gplms/download/octave-3.3.52/doc/interpreter/doc-cache --info-file=/home/gplms/download/octave-3.3.52/doc/interpreter/octave.info
[Thread debugging using libthread_db enabled]
[New Thread 0x2b1f36f2cfb0 (LWP 29677)]

Program received signal SIGSEGV, Segmentation fault.
0x00002b1f358f4988 in sigemptyset () from /home/gplms/download/octave-3.3.52/src/.libs/liboctinterp-3.3.52.so

Commenting those three lines fixes the problem, if i delete gnulib:: it works for me too.

max <mceuskadi>
Sun 29 Aug 2010 02:18:28 PM UTC, comment #6: 

You showed a backtrace from gdb in your original post, but it was not very detailed.  Precisely where in the gnulib sigemptyset function does it crash?

I assumed that removing the gnulib:: namespace qualifier was enough to have your function calling the system sigemptyset function instead of using the gnulib version, but that might not be true.  I haven't looked at precisely how this gnulib module works and I can't reproduce the error, so you or someone else who can reproduce the problem will have to do some debugging to find out what the cause of the problem is.

John W. Eaton <jwe>
Project Administrator
Sun 29 Aug 2010 02:06:03 PM UTC, comment #5: 

For me, removing the "gnulib::" namespace qualifier from those 3 lines also doesn't work (Segmentation fault again).

Some other suggestion?

Leo <muttoni>
Sat 28 Aug 2010 11:56:32 PM UTC, comment #4: 

Removing gnulib:: from those 3 lines, at least for me, results in the same issues.  BTW> I'm running on Mac OS X 10.5.8 i386 Core2Duo, XCode 3.1.3 (Apple gcc 4.0 & MacPorts f95); my install of Octave 3.3.52 is via MacPorts -- I wrote the Portfile and after much testing committed it as is since it seems to work for some users running 10.6.4.  I'll be testing on 10.6.4 soon, once I get a dual-boot partition installed.

Michael Dickens <michaelld>
Fri 27 Aug 2010 06:14:20 PM UTC, comment #3: 

Does it also work if you remove the gnulib:: namespace qualifier from those names?  I.e., then you should just be getting the system sigemptyset and sigaction functions directly instead of using any modified version from gnulib.

In any case, this looks like a problem with gnulib, so the problem really should be fixed there.

Regarding the comment about gnuplot, we would welcome additional help...

John W. Eaton <jwe>
Project Administrator
Mon 23 Aug 2010 01:33:09 AM UTC, comment #2: 

Using Apple's default compiler (GCC 4.2 + Apple changes) on Mac OS X 10.5.8 i386, XCode 3.1.3, I see this same issue and commenting out those lines also works for me.

Michael Dickens <michaelld>
Sun 08 Aug 2010 02:46:09 PM UTC, comment #1: 

Update:

I've found that commenting the lines 198 to 201 of "src/sighandlers.cc" makes "./run-octave" start.

Lines 198 - 201:
---------------------------------------------------
198: //   gnulib::sigemptyset (&act.sa_mask);
199: //   gnulib::sigemptyset (&oact.sa_mask);
200:
201: //   gnulib::sigaction (sig, &act, &oact);
---------------------------------------------------

I know that this is not THE FIX, but can hint where is the root of the problem.

Thanks.

Leo <muttoni>
Sun 08 Aug 2010 02:13:28 PM UTC, original submission:  

I'm trying to upgrade my octave 3.2.2 with 3.3.52 (to see the progress of fltk ploting backend, thas is muchhh faster then the gnuplot turtle),
but, after compiling with make, the command "./gnu-octave" throws a "Segmentation Fault".

------------------------------
Software versions / settings:
------------------------------
Octave-3.3.52
Slackware 12.1 (32 bit) updated with the latest distro packages plus varios others additions/upgrades
Gcc 4.2.3
Lapack version: 3.2.2 (compiled by myself with CFLAGS below)
Blas version: ?.?.? (http://www.netlib.org/blas/blas.tgz downloaded today) (compiled by myself with CFLAGS below)

Compiler related enviromental variables:

  • LDFLAGS=
  • CXXFLAGS=-O -march=nocona
  • CFLAGS=-O -march=nocona

configure command:

  • ./configure --with-fltk-prefix=/usr --enable-shared --disable-docs

make command:

  • make -j2
      • After the successfull compilation, if I try to run 'run-octave', I get :

muttoni@slklinux:~/oct/octave-3.3.52$ ./run-octave
Segmentation fault

      • Further try, with GDB:

muttoni@slklinux:~/oct/octave-3.3.52$ ./run-octave -g
GNU gdb 6.8
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-slackware-linux"...
(gdb) run
(...lot of lines supresed...)
[Thread debugging using libthread_db enabled]
[New Thread 0xb35ab940 (LWP 9143)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb35ab940 (LWP 9143)]
---Type <return> to continue, or q <return> to quit---
0xb772eb6c in sigemptyset () from /home/muttoni/oct/octave-3.3.52/src/.libs/liboctinterp-3.3.52.so

(gdb) bt

#0  0xb772eb6c in sigemptyset () from /home/muttoni/oct/octave-3.3.52/src/.libs/liboctinterp-3.3.52.so
#1  0xb6e77f32 in octave_set_signal_handler () from /home/muttoni/oct/octave-3.3.52/src/.libs/liboctinterp-3.3.52.so
#2  0xb6e77fea in octave_catch_interrupts () from /home/muttoni/oct/octave-3.3.52/src/.libs/liboctinterp-3.3.52.so
#3  0xb6e780af in install_signal_handlers () from /home/muttoni/oct/octave-3.3.52/src/.libs/liboctinterp-3.3.52.so
#4  0xb6e4d017 in octave_main () from /home/muttoni/oct/octave-3.3.52/src/.libs/liboctinterp-3.3.52.so
#5  0x080486be in main ()
(gdb) ^D

-------------------------------------------

I think my system is pretty much well configured, because I can compile and run sucessfully almost all .tar.gz distributed software (except those nasty gnome dependent packages).

Lets go make octave independent of gnuplot (king of slowness) and it will be much better.

Thanks in advance.

Leo <muttoni>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #24978:  diffs.txt added by jwe (2KiB - text/plain)
file #22942:  sighandlers.ii.bz2 added by aquilonis (194KiB - application/x-bzip)
file #21838:  gdb_runs.tar.gz added by muttoni (20KiB - application/gzip - attachment of comment #18)
file #21834:  config.h.gz added by muttoni (15KiB - application/gzip - attachments of comment #18)
file #21835:  libgnu__signal.h.gz added by muttoni (5KiB - application/gzip - attachments of comment #18)
file #21836:  config.log.gz added by muttoni (101KiB - application/gzip - attachments of comment #18)
file #21837:  src__sighandlers.ii.gz added by muttoni (248KiB - application/gzip - attachments of comment #18)
file #21764:  config.log.gz added by muttoni (101KiB - application/x-gzip - config.log.gz: attachment of comment #13.)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by vishalb (Posted a comment)
  • -email is unavailable- added by kent (Posted a comment)
  • -email is unavailable- added by godfrey (Posted a comment)
  • -email is unavailable- added by fangism (Posted a comment)
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by payerle (Posted a comment)
  • -email is unavailable- added by aquilonis (Posted a comment)
  • -email is unavailable- added by abarth (Posted a comment)
  • -email is unavailable- added by mceuskadi (Posted a comment)
  • -email is unavailable- added by jwe (Posted a comment)
  • -email is unavailable- added by michaelld (Posted a comment)
  • -email is unavailable- added by muttoni (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.

     

     

     

    Follow 10 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2012-02-16 jwe StatusNone => Fixed
        Open/ClosedOpen => Closed
    2012-02-04 jwe Attached File- => Added diffs.txt, #24978
    2011-03-17 aquilonis Attached File- => Added sighandlers.ii.bz2, #22942
    2010-10-27 muttoni Attached File- => Added gdb_runs.tar.gz, #21838
    2010-10-27 muttoni Attached File- => Added config.h.gz, #21834
        Attached File- => Added libgnu__signal.h.gz, #21835
        Attached File- => Added config.log.gz, #21836
        Attached File- => Added src__sighandlers.ii.gz, #21837
    2010-10-23 muttoni Attached File- => Added config.log.gz, #21764

    Back to the top


    Powered by Savane 3.5