OpenMP error

Andrew Benson abenson@its.caltech.edu
Sun Feb 13 20:40:00 GMT 2011


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.F90
Type: text/x-fortran
Size: 177 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20110213/acac8e9f/attachment.bin>


More information about the Fortran mailing list