Versions: * gcc: gcc (GCC) 4.2.0 20060715 (experimental) * cpu: AMD-K7 (i686) * kernel: Linux 2.4.21-99 (SuSE 9.0) * glibc: glibc-2.3.6 built with LinuxThreads, _not_ NPTL Test program: ============================== omp-test1.c ======================= #include <stdlib.h> #include <stdio.h> /* A computational task whose duration depends on x. */ int job (int x) { int j = rand() % (100 + 10 * x); int i; for (i = j - 1; i > 0; i--) if (j % i == 0) break; return i; } int main (int argc, char *argv[]) { int n = 10000; int *mem = malloc (n * sizeof (int)); int i; /* Because the tasks don't have all the same duration, a dynamic schedule is best. */ #pragma omp parallel for schedule(dynamic) for (i = 0; i < n; i++) mem[i] = job (i); for (i = 0; i < n; i++) printf ("mem[%d] = %d\n", i, mem[i]); return 0; } ===================================================================== $ gcc -fopenmp -Wall -O omp-test1.c The single-threaded program runs fine: $ unset OMP_NUM_THREADS; ./a.out or $ export OMP_NUM_THREADS=1; ./a.out But with more than one thread it crashes: $ export OMP_NUM_THREADS=2; ./a.out Segmentation fault (core dumped) $ gdb a.out core.26661 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 "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `./a.out'. Program terminated with signal 11, Segmentation fault. Reading symbols from /gfs/ibook/Volumes/ExtData/bin.x86-linux/gnu-inst-gcc/4.2-20060715/lib/gcc/i686-pc-linux-gnu/4.2.0/libgomp.so.1...done. Loaded symbols for /packages/gnu-inst-gcc/4.2-20060715/lib/gcc/i686-pc-linux-gnu/4.2.0/libgomp.so.1 Reading symbols from /lib/libpthread.so.0...done. Loaded symbols for /lib/libpthread.so.0 Reading symbols from /lib/libc.so.6...done. Loaded symbols for /lib/libc.so.6 Reading symbols from /lib/librt.so.1...done. Loaded symbols for /lib/librt.so.1 Reading symbols from /lib/ld-linux.so.2...done. Loaded symbols for /lib/ld-linux.so.2 #0 gomp_iter_dynamic_next (pstart=0xbfffe9c4, pend=0xbfffe9c8) at ../../../gcc-4.2-20060715/libgomp/iter.c:189 189 start = ws->next; (gdb) where #0 gomp_iter_dynamic_next (pstart=0xbfffe9c4, pend=0xbfffe9c8) at ../../../gcc-4.2-20060715/libgomp/iter.c:189 #1 0x4001c8e8 in gomp_loop_dynamic_next (istart=0xbfffe9c4, iend=0xbfffe9c8) at ../../../gcc-4.2-20060715/libgomp/loop.c:248 #2 0x080486ed in main.omp_fn.0 () #3 0x0804861e in main () (gdb) print ws $1 = (struct gomp_work_share *) 0x0
It's still reproducible with gcc-4.2-20061031: $ export OMP_NUM_THREADS=2 $ 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 "i686-pc-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /dev/shm/a.out [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 4983)] [New Thread 32769 (LWP 4984)] [New Thread 16386 (LWP 4985)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16386 (LWP 4985)] gomp_iter_dynamic_next (pstart=0xbf7ffa94, pend=0xbf7ffa98) at ../../../gcc-4.2-20061031/libgomp/iter.c:189 189 start = ws->next; (gdb) where #0 gomp_iter_dynamic_next (pstart=0xbf7ffa94, pend=0xbf7ffa98) at ../../../gcc-4.2-20061031/libgomp/iter.c:189 #1 0x4001ca78 in gomp_loop_dynamic_next (istart=0xbf7ffa94, iend=0xbf7ffa98) at ../../../gcc-4.2-20061031/libgomp/loop.c:248 #2 0x080486ed in main.omp_fn.0 () #3 0x4001de5d in gomp_thread_start (xdata=0xbfffe580) at ../../../gcc-4.2-20061031/libgomp/team.c:108 #4 0x4003bfe6 in pthread_start_thread (arg=0xbf7ffbe0) at manager.c:310 #5 0x4003c07f in pthread_start_thread_event (arg=0xbf7ffbe0) at manager.c:334 #6 0x4014e0aa in clone () from /lib/libc.so.6
Was LinuxThreads built at least --with-tls support or without? If without and libgomp has been built without --disable-tls and your assembler/linker support TLS, libgomp might be using __thread eventhough glibc doesn't support that. There have been some patches added recently to improve gcc configure checks for the runtime support of TLS.
> Was LinuxThreads built at least --with-tls support or without? The glibc was built with LinuxThreads without TLS. (I gave --without-tls explicitly to the glibc build.) > If without and libgomp has been built without --disable-tls and your > assembler/linker support TLS, libgomp might be using __thread eventhough > glibc doesn't support that. Yes, this is exactly the problem; see the analysis and patch in http://gcc.gnu.org/ml/gcc/2006-11/msg00244.html > There have been some patches added recently to improve gcc configure checks > for the runtime support of TLS. The only patch that has been committed is this one from Daniel Jacobowitz http://gcc.gnu.org/viewcvs/trunk/config/tls.m4?r1=117049&r2=118777 It has no effect on this bug, since it applies only to the cross-compiling case. For the native compile, I posted a patch that is known to fix this bug: http://gcc.gnu.org/ml/gcc/2006-11/msg00244.html It has been approved by Richard Henderson: http://gcc.gnu.org/ml/gcc/2006-11/msg00255.html But noone has committed it to the GCC SVN. Could someone please commit this patch on the HEAD and possibly on the 4.2 branch? (It is not a regression, if you argue that libgomp and -fopenmp is a new feature. But it is a regression if you argue that there are packages out there, such as GNU gettext 0.16, which use -fopenmp if available, and this bug turns a program that would run unparallelized but correctly with gcc-4.1 into a program that runs parallelized but crashes with gcc-4.2.)
Subject: Bug 28468 Author: jakub Date: Wed Feb 7 13:35:17 2007 New Revision: 121689 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=121689 Log: 2007-02-07 Bruno Haible <bruno@clisp.org> config/ PR libgomp/28468 * config/tls.m4 (GCC_CHECK_TLS): Also check whether the libc supports TLS via __thread. 2007-02-07 Jakub Jelinek <jakub@redhat.com> {libgomp,libstdc++-v3,libmudflap,libjava}/ PR libgomp/28468 * configure: Regenerate. Modified: trunk/config/ChangeLog trunk/config/tls.m4 trunk/libgomp/ChangeLog trunk/libgomp/configure trunk/libjava/ChangeLog trunk/libjava/configure trunk/libmudflap/ChangeLog trunk/libmudflap/configure trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/configure
Approved offline by Alex Oliva, committed so far on the trunk. Will backport to 4.2 branch after a week or so on the trunk.
Did you backport the fix to 4.2?
No plaans to backport this to 4.2 anymore.