Bug 39176 - -static and -fopenmp and io causes segfault
Summary: -static and -fopenmp and io causes segfault
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: libgomp (show other bugs)
Version: 4.4.0
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks:
 
Reported: 2009-02-13 11:40 UTC by Joost VandeVondele
Modified: 2009-02-13 21:10 UTC (History)
2 users (show)

See Also:
Host:
Target: x86_64-unknown-linux-gnu
Build:
Known to work: 4.3.1
Known to fail: 4.4.0
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joost VandeVondele 2009-02-13 11:40:21 UTC
I noticed this running mixed mpi/openmp on a system that required an executable without dynamics libraries. Don't know if the Fortran IO is supposed to be thread safe (i.e. serialized thread safe), but this seems to work without -static. It also appears to work with 4.3.1 but not 4.4 (trunk)

> cat test.f90
!$OMP PARALLEL
!$OMP CRITICAL
 write(6,*) "Hello world"
!$OMP END CRITICAL
!$OMP END PARALLEL
 write(6,*) "Done!"
END

> gfortran -static -fopenmp test.f90
> ./a.out
Segmentation fault
> gdb ./a.out
GNU gdb 6.4
Copyright 2005 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 "x86_64-suse-linux"...Using host libthread_db library                            "/lib64/libthread_db.so.1".

(gdb) run
Starting program: /data/vondele/omptest/a.out

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x000000000040642f in get_external_unit (n=6, do_create=1)
    at /data/vondele/gcc_trunk/gcc/libgfortran/../gcc/gthr-posix.h:704
#2  0x0000000000404c01 in data_transfer_init (dtp=0x7fff047208c0, read_flag=0)
    at /data/vondele/gcc_trunk/gcc/libgfortran/io/transfer.c:1828
#3  0x00000000004003d6 in MAIN__.omp_fn.0 ()
#4  0x000000000040032c in MAIN__ ()
#5  0x000000000040042c in main (argc=1, argv=0x7fff04720fa8)
    at /data/vondele/gcc_trunk/gcc/libgfortran/fmain.c:21
(gdb)
Comment 1 Joost VandeVondele 2009-02-13 11:42:10 UTC
adding Jakub
Comment 2 Jakub Jelinek 2009-02-13 11:50:50 UTC
This has been repeated many times.  Don't use -static for threaded programs, it is really bad idea, and if you really have to, you need to link the whole libpthread.a in (-Wl,--whole-archive -lpthread -Wl,--no-whole-archive), otherwise if it works, it is by pure luck.
This certainly isn't a regression.
Comment 3 Joost VandeVondele 2009-02-13 12:19:57 UTC
(In reply to comment #2)
> This has been repeated many times.  Don't use -static for threaded programs, it
> is really bad idea, and if you really have to, you need to link the whole
> libpthread.a in (-Wl,--whole-archive -lpthread -Wl,--no-whole-archive),
> otherwise if it works, it is by pure luck.
> This certainly isn't a regression.
> 

Thanks for your reply, this was unknown to me, and I think for many occassional omp users. Do you think this could be documented near the -fopenmp flag (I can write something if you wish). Or could one have gcc warn if both -fopenmp and -static are present ?
Comment 4 Jakub Jelinek 2009-02-13 12:35:43 UTC
It is glibc specific, on the other hand it isn't particularly -fopenmp related.
I guess easiest will be if glibc stops shipping libpthread.a.
Comment 5 Joost VandeVondele 2009-02-13 14:01:13 UTC
(In reply to comment #4)
> It is glibc specific, on the other hand it isn't particularly -fopenmp related.
> I guess easiest will be if glibc stops shipping libpthread.a.

but if -fopenmp automatically adds -lpthread maybe it should do it in the 'proper' way if -static is also on the command line (eventually bailing out if libpthread.a can not be found)? 

Note, e.g. a warning is produced for similar issues already, e.g. I see:

/home/u1/vondele/gcc_trunk/build/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../lib64/libgfortran.a(getlog.o): In function `_gfortran_getlog':
/home/u1/vondele/gcc_trunk/gcc/libgfortran/intrinsics/getlog.c:82: warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

let me reopen the bug, removing the regression marker, and as an enhancement. I think that a warning, or adding -lpthread in the 'proper' way if -static will save many other users from loosing time on this one.
Comment 6 Andrew Pinski 2009-02-13 20:18:05 UTC
Not a gcc bug so closing as invalid.  That warning comes from glibc anyways.
Comment 7 Joost VandeVondele 2009-02-13 21:00:22 UTC
(In reply to comment #6)
> Not a gcc bug so closing as invalid.  

The gcc  'bug' is that -fopenmp -static should link to pthreads as 
-Wl,--whole-archive -lpthread -Wl,--no-whole-archive, if that is required, or error out if that is not possible. 

The current way of just adding -lpthread and hoping it is correct (even in the presence of -static) is leading to wrong code.
Comment 8 Jakub Jelinek 2009-02-13 21:10:00 UTC
This is not a gcc bug, glibc either should not ship libpthread.a at all or
mv libpthread.a libpthreadx.a; gcc -r -nostdlib -o libpthread.a --whole-archive libpthreadx.a; rm libpthreadx.a
I'll try the latter in Fedora soon.
In any case, users really shouldn't use -static except for a few system recovery tools, see
http://people.redhat.com/drepper/no_static_linking.html