public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "dvyukov at google dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives Date: Sat, 29 Dec 2012 09:38:00 -0000 [thread overview] Message-ID: <bug-55561-4-myDd4PC6Y2@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-55561-4@http.gcc.gnu.org/bugzilla/> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #19 from Dmitry Vyukov <dvyukov at google dot com> 2012-12-29 09:38:13 UTC --- On Wed, Dec 26, 2012 at 12:23 AM, Joost.VandeVondele at mat dot ethz.ch <gcc-bugzilla@gcc.gnu.org> wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 > > --- Comment #16 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-12-25 20:23:07 UTC --- > many things appear to work fine, but seemingly parallel do loops with a dynamic > schedule generate warnings in libgomp. I also seem to observe that they are not > strictly deterministic, sometimes these warnings happen, sometimes not. > > Testcase: > > !$OMP PARALLEL PRIVATE(j) > > j=OMP_GET_THREAD_NUM() > > ! no warnings without the dynamic schedule > !$OMP DO SCHEDULE(DYNAMIC,2) > DO i=1,10 > ENDDO > > !$OMP END PARALLEL > END > > Result: > > vjoost@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out > vjoost@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out > vjoost@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out > vjoost@nanosim-s01.ethz.ch:/data/vjoost/clean/cp2k/cp2k/src> ./a.out > ================== > WARNING: ThreadSanitizer: data race (pid=35190) > Read of size 8 at 0x7d3000027290 by main thread: > #0 gomp_iter_dynamic_next > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/iter.c:190 > (libgomp.so.1+0x000000006678) > #1 GOMP_loop_dynamic_start > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/loop.c:128 > (libgomp.so.1+0x000000007a03) > #2 MAIN__._omp_fn.0 test.f90:0 (exe+0x000000000d7d) > #3 MAIN__ test.f90:0 (exe+0x000000000ccb) > #4 main ??:0 (exe+0x000000000d1a) > > Previous write of size 8 at 0x7d3000027290 by thread 1: > #0 gomp_loop_init > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/loop.c:41 > (libgomp.so.1+0x000000007a96) > #1 MAIN__._omp_fn.0 test.f90:0 (exe+0x000000000d7d) > #2 gomp_thread_start > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:116 > (libgomp.so.1+0x00000000d012) > > Location is heap block of size 1568 at 0x7d3000027100 allocated by main > thread: > #0 malloc ??:0 (libtsan.so.0+0x00000001896e) > #1 gomp_malloc > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/alloc.c:36 > (libgomp.so.1+0x00000000417a) > #2 gomp_new_team > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:145 > (libgomp.so.1+0x00000000d27a) > #3 GOMP_parallel_start > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/parallel.c:108 > (libgomp.so.1+0x00000000afc7) > #4 MAIN__ test.f90:0 (exe+0x000000000cc1) > #5 main ??:0 (exe+0x000000000d1a) > > Thread 1 (tid=35191, running) created at: > #0 pthread_create ??:0 (libtsan.so.0+0x00000001a868) > #1 gomp_team_start > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/team.c:440 > (libgomp.so.1+0x00000000d908) > #2 GOMP_parallel_start > /data/vjoost/gnu/gcc_trunk/obj/x86_64-unknown-linux-gnu/libgomp/../../../gcc/libgomp/parallel.c:108 > (libgomp.so.1+0x00000000afd7) > #3 MAIN__ test.f90:0 (exe+0x000000000cc1) > #4 main ??:0 (exe+0x000000000d1a) Looks like unsafe publication of gomp_work_share data. Can you show disassembly of > #2 MAIN__._omp_fn.0 test.f90:0 (exe+0x000000000d7d) ? How does it choose between calling gomp_loop_init() and GOMP_loop_dynamic_start()? Humm... do omp generated functions (like MAIN__._omp_fn.0) pass through tsan pass? Perhaps it contains some atomic op that tsan does not see.
next prev parent reply other threads:[~2012-12-29 9:38 UTC|newest] Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top 2012-12-02 8:16 [Bug sanitizer/55561] New: TSAN crashes for Fortran Joost.VandeVondele at mat dot ethz.ch 2012-12-02 9:21 ` [Bug sanitizer/55561] " dvyukov at google dot com 2012-12-02 9:30 ` Joost.VandeVondele at mat dot ethz.ch 2012-12-02 9:36 ` dvyukov at google dot com 2012-12-02 10:28 ` kcc at gcc dot gnu.org 2012-12-02 21:11 ` jakub at gcc dot gnu.org 2012-12-03 7:42 ` Joost.VandeVondele at mat dot ethz.ch 2012-12-10 12:44 ` Joost.VandeVondele at mat dot ethz.ch 2012-12-10 12:47 ` pinskia at gcc dot gnu.org 2012-12-10 12:53 ` Joost.VandeVondele at mat dot ethz.ch 2012-12-10 12:57 ` dvyukov at google dot com 2012-12-10 12:59 ` Joost.VandeVondele at mat dot ethz.ch 2012-12-10 15:07 ` dvyukov at google dot com 2012-12-10 15:56 ` Joost.VandeVondele at mat dot ethz.ch 2012-12-11 9:48 ` [Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives Joost.VandeVondele at mat dot ethz.ch 2012-12-25 19:30 ` Joost.VandeVondele at mat dot ethz.ch 2012-12-25 20:23 ` Joost.VandeVondele at mat dot ethz.ch 2012-12-26 19:35 ` Joost.VandeVondele at mat dot ethz.ch 2012-12-29 9:33 ` dvyukov at google dot com 2012-12-29 9:38 ` dvyukov at google dot com [this message] 2012-12-29 10:13 ` dvyukov at google dot com 2012-12-29 10:21 ` dvyukov at google dot com 2012-12-30 9:03 ` Joost.VandeVondele at mat dot ethz.ch 2012-12-30 9:58 ` dvyukov at google dot com 2012-12-30 10:11 ` dvyukov at google dot com 2012-12-30 14:53 ` Joost.VandeVondele at mat dot ethz.ch 2012-12-30 17:07 ` dvyukov at google dot com 2012-12-30 19:57 ` Joost.VandeVondele at mat dot ethz.ch 2013-01-01 17:14 ` Joost.VandeVondele at mat dot ethz.ch 2013-01-02 9:09 ` dvyukov at google dot com 2013-01-02 9:44 ` jakub at gcc dot gnu.org 2013-01-02 10:28 ` dvyukov at google dot com 2013-01-07 21:35 ` Joost.VandeVondele at mat dot ethz.ch 2013-01-08 9:17 ` dvyukov at google dot com 2013-01-10 11:27 ` Joost.VandeVondele at mat dot ethz.ch 2013-01-10 11:37 ` jakub at gcc dot gnu.org 2013-01-31 7:43 ` amodra at gmail dot com 2013-01-31 14:29 ` jakub at gcc dot gnu.org 2013-01-31 16:57 ` jakub at gcc dot gnu.org 2013-02-01 20:00 ` dvyukov at google dot com 2013-03-29 8:11 ` [Bug sanitizer/55561] TSAN: provide a TSAN instrumented libgomp Joost.VandeVondele at mat dot ethz.ch 2013-06-03 13:21 ` dvyukov at google dot com 2014-01-21 12:44 ` emil.styrke at gmail dot com 2014-01-22 8:14 ` Joost.VandeVondele at mat dot ethz.ch 2014-05-08 19:49 ` roland at rschulz dot eu 2014-05-09 5:38 ` Joost.VandeVondele at mat dot ethz.ch 2014-05-09 10:26 ` dvyukov at google dot com 2014-05-14 19:17 ` Joost.VandeVondele at mat dot ethz.ch 2014-05-14 19:25 ` dvyukov at google dot com 2014-07-09 6:07 ` roland at rschulz dot eu 2014-07-09 7:12 ` jakub at gcc dot gnu.org 2014-07-09 7:17 ` Joost.VandeVondele at mat dot ethz.ch 2024-02-29 17:27 ` egallager at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-55561-4-myDd4PC6Y2@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).