[Bug libgomp/28456] New: [gomp] Segmentation fault with statically linked binaries

[Bug libgomp/28456] New: [gomp] Segmentation fault with statically linked binaries

[anlauf at gmx dot de]

Hi,

I am experiencing the problem that while a dynamically linked
simple OpenMP test program works, its statically linked variant
crashes.  (It works with Intel's icc in all tested cases).

Caveat: for this report I am using the daily binaries built
by Francois Coudert, which are available from
  http://quatramaran.ens.fr/~coudert/gfortran
These binaries contain gcc and gfortran.

I could reproduce the problem detailed below on four different
systems with different x86 processors: Suse 8.2, Suse 9.0 and
Debian 3.1r1 (all glibc-2.3.2), and a Suse 10.0 (glibc-2.3.5)
one, on which this report is based.  It may be possible that
Francois' configuration is incompatible with these systems.
In that case I would appreciate a hint that I could forward to him.
If it is just is a genuine bug with libgomp, it needs fixing.

(The compiler is installed under /tmp/irun).

% cat openmp-test.c 
#include <stdio.h>
#ifdef _OPENMP
#include <omp.h>
#endif

int main(int argc, char *argv[])
{
#ifdef _OPENMP
    printf("OpenMP enabled during compilation.\n");
    printf("Number of Processors: %d\n", omp_get_num_procs());
#else
    printf("OpenMP not available.\n");
#endif /* _OPENMP */
    printf("Done.\n");
    return 0;
}

Demonstration that the program works with shared libs:

% /tmp/irun/bin/gcc -g -fopenmp -I /tmp/irun/include openmp-test.c
% LD_LIBRARY_PATH=/tmp/irun/lib ./a.out 
OpenMP enabled during compilation.
Number of Processors: 1
Done.

Demonstration of failure (segementation fault) with static linking:

% /tmp/irun/bin/gcc -v -g -static -fopenmp -I /tmp/irun/include openmp-test.c
Using built-in specs.
Target: i386-linux
Configured with: ../gcc/configure
--prefix=/cosmic/coudert/tmp/gfortran-20060721/irun
--enable-languages=c,fortran --host=i386-linux
--with-gmp=/cosmic/coudert/tmp/gfortran-20060721/gfortran_libs
Thread model: posix
gcc version 4.2.0 20060721 (experimental)
 /tmp/irun/bin/../libexec/gcc/i386-linux/4.2.0/cc1 -quiet -v -I
/tmp/irun/include -iprefix /tmp/irun/bin/../lib/gcc/i386-linux/4.2.0/
-D_REENTRANT openmp-test.c -quiet -dumpbase openmp-test.c -mtune=i386 -auxbase
openmp-test -g -version -fopenmp -o /tmp/ccwo3Tmc.s
ignoring nonexistent directory
"/tmp/irun/bin/../lib/gcc/i386-linux/4.2.0/../../../../i386-linux/include"
ignoring nonexistent directory
"/cosmic/coudert/tmp/gfortran-20060721/irun/include"
ignoring nonexistent directory
"/cosmic/coudert/tmp/gfortran-20060721/irun/lib/gcc/i386-linux/4.2.0/include"
ignoring nonexistent directory
"/cosmic/coudert/tmp/gfortran-20060721/irun/i386-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /tmp/irun/include
 /tmp/irun/bin/../lib/gcc/i386-linux/4.2.0/include
 /usr/local/include
 /usr/include
End of search list.
GNU C version 4.2.0 20060721 (experimental) (i386-linux)
        compiled by GNU C version 4.2.0 20060721 (experimental).
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 3952dd239fbe9f5cb570065a83739006
 as -V -Qy -o /tmp/ccukLdwm.o /tmp/ccwo3Tmc.s
GNU assembler version 2.16.91.0.2 (i586-suse-linux) using BFD version
2.16.91.0.2 20050720 (SuSE Linux)
Reading specs from
/tmp/irun/bin/../lib/gcc/i386-linux/4.2.0/../../../libgomp.spec
 /tmp/irun/bin/../libexec/gcc/i386-linux/4.2.0/collect2 -m elf_i386 -static
/usr/lib/crt1.o /usr/lib/crti.o
/tmp/irun/bin/../lib/gcc/i386-linux/4.2.0/crtbeginT.o
-L/tmp/irun/bin/../lib/gcc/i386-linux/4.2.0 -L/tmp/irun/bin/../lib/gcc
-L/tmp/irun/bin/../lib/gcc/i386-linux/4.2.0/../../.. /tmp/ccukLdwm.o -lgomp
-lrt -lpthread --start-group -lgcc -lgcc_eh -lpthread -lc --end-group
/tmp/irun/bin/../lib/gcc/i386-linux/4.2.0/crtend.o /usr/lib/crtn.o


% gdb a.out 
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-suse-linux"...Using host libthread_db library
"/lib/tls/libthread_db.so.1".

(gdb) run
Starting program: /tmp/a.out 

Program received signal SIGSEGV, Segmentation fault.
0x08048bba in initialize_team () at sem.h:75
75      sem.h: No such file or directory.
        in sem.h
(gdb) where
#0  0x08048bba in initialize_team () at sem.h:75
#1  0x0809dad6 in __do_global_ctors_aux ()
#2  0x08048145 in _init ()
#3  0x0804f85b in __libc_csu_init ()
#4  0x00000000 in ?? ()
#5  0x0804f8b0 in __libc_csu_init ()
#6  0xbffa36a8 in ?? ()
#7  0x0804f65c in __libc_start_main ()
#8  0x0804f65c in __libc_start_main ()
#9  0x08048171 in _start () at start.S:119
(gdb) 

The crash appears to occurs during the initialization phase of
libgomp, before the main program starts.  Setting a breakpoint
before the first printf shows that it is not reached.

Any ideas?

Cheers,
-ha


-- 
           Summary: [gomp] Segmentation fault with statically linked
                    binaries
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgomp
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: anlauf at gmx dot de
  GCC host triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28456

[Bug libgomp/28456] [gomp] Segmentation fault with statically linked binaries

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-07-21 22:50 -------
I think this is a bug in your glibc version where static linking glibc causes
TLS to be broken.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28456

[Bug libgomp/28456] [gomp] Segmentation fault with statically linked binaries

[anlauf at gmx dot de]

------- Comment #2 from anlauf at gmx dot de  2006-07-22 12:55 -------
(In reply to comment #1)
> I think this is a bug in your glibc version where static linking glibc causes
> TLS to be broken.

Andrew,

how can I find out whether this happens, and why should it happen
with static linking only?  Is there a workaround for static linking?

The distributions' glibc versions, whether static or dynamic, are
supposedly the same.

For the glibc on the system mentioned above, the dynamic version claims:
% /lib/libc.so.6 
GNU C Library stable release version 2.3.5 (20050802), by Roland McGrath et al.
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Configured for i686-suse-linux.
Compiled by GNU CC version 4.0.2 20050901 (prerelease) (SUSE Linux).
Compiled on a Linux 2.6.12 system on 2005-09-09.
Available extensions:
        GNU libio by Per Bothner
        crypt add-on version 2.1 by Michael Glad and others
        linuxthreads-0.10 by Xavier Leroy
        GNU Libidn by Simon Josefsson
        NoVersion patch for broken glibc 2.0 binaries
        BIND-8.2.3-T5B
        libthread_db work sponsored by Alpha Processor Inc
        NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Thread-local storage support included.
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

Cheers,
-ha


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28456

[Bug libgomp/28456] [gomp] Segmentation fault with statically linked binaries

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-07-22 22:28 -------
Because less people test glibc staticly.  Anyways this is a glibc bug which has
since been fixed and it is the same problem as mentioned in PR 28351 so closing
as a dup of that bug.

*** This bug has been marked as a duplicate of 28351 ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28456

[Bug libgomp/28456] [gomp] Segmentation fault with statically linked binaries

[anlauf at gmx dot de]

------- Comment #4 from anlauf at gmx dot de  2006-07-23 21:06 -------
(In reply to comment #3)
> Because less people test glibc staticly.  Anyways this is a glibc bug which has
> since been fixed and it is the same problem as mentioned in PR 28351 so closing
> as a dup of that bug.

Negative.  I cannot reproduce the bug PR 28351 on the machines I have
access to which are i386 (32 bit).  I don't believe it is the same bug.


-- 

anlauf at gmx dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|DUPLICATE                   |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28456

[Bug libgomp/28456] [gomp] Segmentation fault with statically linked binaries

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2006-07-23 23:56 -------
No, it is still the same bug in glibc even though it is a different target and
32bit vs 64bit.

*** This bug has been marked as a duplicate of 28351 ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28456

[Bug libgomp/28456] [gomp] Segmentation fault with statically linked binaries

[anlauf at gmx dot de]

------- Comment #6 from anlauf at gmx dot de  2006-07-24 08:06 -------
(In reply to comment #5)
> No, it is still the same bug in glibc even though it is a different target and
> 32bit vs 64bit.
> 
> *** This bug has been marked as a duplicate of 28351 ***

Andy, please show me a testcase that fails on 32bit.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28456

[Bug libgomp/28456] [gomp] Segmentation fault with statically linked binaries

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2006-07-24 08:09 -------
(In reply to comment #6)
> Andy, please show me a testcase that fails on 32bit.

Any old TLS testcase will do.  Also I am not Andy but Andrew.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28456

[Bug libgomp/28456] [gomp] Segmentation fault with statically linked binaries

[anlauf at gmx dot de]

------- Comment #8 from anlauf at gmx dot de  2006-07-24 08:13 -------
(In reply to comment #7)
> (In reply to comment #6)
> > Andy, please show me a testcase that fails on 32bit.
> 
> Any old TLS testcase will do.  Also I am not Andy but Andrew.

So could you please point me to one?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28456

[Bug libgomp/28456] [gomp] Segmentation fault with statically linked binaries

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2006-07-26 00:31 -------
(In reply to comment #8)
> So could you please point me to one?

Something like:

__thread int i;

int main(void)
{
  return i;
}

Though it might need also another thread to be started too.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28456