OpenMP error

[Andrew Benson <abenson at its dot caltech dot edu>]

My application is segfaulting when compile with gfortran 4.6 r170108 using 
OpenMP. Running it through valgrind I'm seeing an warning about uninitialized 
bytes in syscall param futex(utime) before the segfault occurs. I don't know 
if this is expected (I haven't seen it before) or if this eventually leads to 
the segfault but my code was running OK under earlier revisions of gfortran 
4.6 so I figured it was worth mentioning this.

I've attached a (very minimal) test case that reproduces this error:

$ gfortran test.F90 -o test.exe -fopenmp
$ valgrind --track-origins=yes test.exe
==15748== Memcheck, a memory error detector
==15748== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al.
==15748== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==15748== Command: test.exe
==15748== 
==15748== Syscall param futex(utime) contains uninitialised byte(s)
==15748==    at 0x304917: syscall (in /lib/libc-2.5.so)
==15748==    by 0x4130728: gomp_mutex_lock_slow (futex.h:44)
==15748==    by 0x80486A5: MAIN__._omp_fn.0 (in 
/home/abenson/Galacticus/v0.9.0_gcc4.6/test.exe)
==15748==    by 0x8048651: MAIN__ (in 
/home/abenson/Galacticus/v0.9.0_gcc4.6/test.exe)
==15748==    by 0x804868C: main (in 
/home/abenson/Galacticus/v0.9.0_gcc4.6/test.exe)
==15748==  Uninitialised value was created by a stack allocation
==15748==    at 0x4130694: gomp_mutex_lock_slow (mutex.c:36)
==15748== 
==15748== Thread 2:
==15748== Syscall param futex(utime) contains uninitialised byte(s)
==15748==    at 0x304917: syscall (in /lib/libc-2.5.so)
==15748==    by 0x4130FAD: gomp_team_barrier_wait_end (futex.h:44)
==15748==    by 0x41310AD: gomp_team_barrier_wait (bar.c:121)
==15748==    by 0x412F54B: gomp_thread_start (team.c:116)
==15748==    by 0x3C8831: start_thread (in /lib/libpthread-2.5.so)
==15748==    by 0x3080AD: clone (in /lib/libc-2.5.so)
==15748==  Uninitialised value was created by a stack allocation
==15748==    at 0x4130EE4: gomp_team_barrier_wait_end (bar.c:83)
==15748== 
==15748== 
==15748== HEAP SUMMARY:
==15748==     in use at exit: 1,756 bytes in 4 blocks
==15748==   total heap usage: 20 allocs, 16 frees, 4,721 bytes allocated
==15748== 
==15748== LEAK SUMMARY:
==15748==    definitely lost: 0 bytes in 0 blocks
==15748==    indirectly lost: 0 bytes in 0 blocks
==15748==      possibly lost: 144 bytes in 1 blocks
==15748==    still reachable: 1,612 bytes in 3 blocks
==15748==         suppressed: 0 bytes in 0 blocks
==15748== Rerun with --leak-check=full to see details of leaked memory
==15748== 
==15748== For counts of detected and suppressed errors, rerun with: -v
==15748== ERROR SUMMARY: 33 errors from 2 contexts (suppressed: 23 from 8)

I could also attempt to make a test case for the resulting segfault, but that 
will take some time.

-Andrew.

-- 

* Andrew Benson: http://www.tapir.caltech.edu/~abenson/contact.html

* Galacticus: http://sites.google.com/site/galacticusmodel

program Test
  implicit none
  
  !$omp parallel
  !$omp critical(Initialization) 
  call sleep(1)
  !$omp end critical(Initialization)
  !$omp end parallel
  
end program Test