1

openmpを使用するCPPコードがあります。fortran90コードにリンクされています。1つのスレッドで実行する場合、すべてが正常です。1とは異なる任意の数のスレッドで実行すると、cpp部分を終了するときにセグメンテーション違反が発生します。コードの結果は正確であり、エラーは一切ありません。終了するまで、スムーズに実行されます。openmpに関連するコードの一部は次のとおりです。

#pragma omp parallel for shared(even_phi,odd_phi,odd_divisor,odd_start_index,odd_iter_index) private(ii,jj,kk,cc,io,pp,f1,f2,f3,f4,f5,f6,ff,tmp_phi) schedule(static)
            for (kk=1; kk<nz-1; kk++)
            {
                cc = (kk-1)*(ny-2);

                for (jj=1; jj<ny-1; jj++)
                {
                    io = odd_start_index[cc];
                    pp = odd_iter_index[cc++];

                    for (ii=io; ii<maxElem; ii++)
                    {
                        f1 = even_phi[pp-odown];
                        f2 = even_phi[pp-oright];
                        f3 = even_phi[pp];
                        tmp_phi = odd_phi[pp];
                        f4 = even_phi[pp+1];
                        f5 = even_phi[pp+oleft];
                        f6 = even_phi[pp+oup];

                        ff = f1+f2+f3+f4+f5+f6;

                        odd_phi[pp] = odd_divisor[pp]*ff + c2*tmp_phi;

                        pp++;
                    }
                }
            }

これは標準の数値ソルバーコードです。これもopenmpなしで、OMP_NUM_THREADS=1で完全に機能します。より多くのスレッドで実行された場合、ほぼ完全な通常の実行の後、Valgrindsは次のように述べています。

==23723== Thread 20:
==23723== Jump to the invalid address stated on the next line
==23723==    at 0x2A6EBBB8: ???
==23723==    by 0x2A6EA515: ???
==23723==  Address 0x2a6ebbb8 is not stack'd, malloc'd or (recently) free'd
==23723== 
==23723== 
==23723== Process terminating with default action of signal 11 (SIGSEGV)
==23723==  Access not within mapped region at address 0x2A6EBBB8
==23723==    at 0x2A6EBBB8: ???
==23723==    by 0x2A6EA515: ???
==23723==  If you believe this happened as a result of a stack
==23723==  overflow in your program's main thread (unlikely but
==23723==  possible), you can try to increase the size of the
==23723==  main thread stack using the --main-stacksize= flag.
==23723==  The main thread stack size used in this run was 1048576.
==23723== 
==23723== HEAP SUMMARY:
==23723==     in use at exit: 632,995,339 bytes in 101 blocks
==23723==   total heap usage: 10,071 allocs, 9,970 frees, 1,257,933,743 bytes allocated
==23723== 
==23723== Thread 1:
==23723== 6,992 bytes in 23 blocks are possibly lost in loss record 47 of 74
==23723==    at 0x4A04A28: calloc (vg_replace_malloc.c:467)
==23723==    by 0x35A0E11812: _dl_allocate_tls (dl-tls.c:300)
==23723==    by 0x35A1E07068: pthread_create@@GLIBC_2.2.5 (allocatestack.c:571)
==23723==    by 0x2A6EA981: ???
==23723==    by 0x2A4C666E: ???
==23723==    by 0x4C8DB7: solvermodule (in /home/tom/bin/solver)
==23723==    by 0x4C6794: MAIN__ (qdiff4v.f90:749)
==23723==    by 0x4C8DF9: main (in /home/tom/bin/solver)
==23723== 
==23723== 30,276 bytes in 1 blocks are definitely lost in loss record 50 of 74
==23723==    at 0x4A0674C: operator new[](unsigned long) (vg_replace_malloc.c:305)
==23723==    by 0x2A4C6394: ???
==23723==    by 0x4C8DB7: solvermodule (in /home/tom/bin/solver)
==23723==    by 0x4C6794: MAIN__ (qdiff4v.f90:749)
==23723==    by 0x4C8DF9: main (in /home/tom/bin/solver)
==23723== 
==23723== 30,276 bytes in 1 blocks are definitely lost in loss record 51 of 74
==23723==    at 0x4A0674C: operator new[](unsigned long) (vg_replace_malloc.c:305)
==23723==    by 0x2A4C63BF: ???
==23723==    by 0x4C8DB7: solvermodule (in /home/tom/bin/solver)
==23723==    by 0x4C6794: MAIN__ (qdiff4v.f90:749)
==23723==    by 0x4C8DF9: main (in /home/tom/bin/solver)
==23723== 
==23723== 30,276 bytes in 1 blocks are definitely lost in loss record 52 of 74
==23723==    at 0x4A0674C: operator new[](unsigned long) (vg_replace_malloc.c:305)
==23723==    by 0x2A4C63EA: ???
==23723==    by 0x4C8DB7: solvermodule (in /home/tom/bin/solver)
==23723==    by 0x4C6794: MAIN__ (qdiff4v.f90:749)
==23723==    by 0x4C8DF9: main (in /home/tom/bin/solver)
==23723== 
==23723== 30,276 bytes in 1 blocks are definitely lost in loss record 53 of 74
==23723==    at 0x4A0674C: operator new[](unsigned long) (vg_replace_malloc.c:305)
==23723==    by 0x2A4C6415: ???
==23723==    by 0x4C8DB7: solvermodule (in /home/tom/bin/solver)
==23723==    by 0x4C6794: MAIN__ (qdiff4v.f90:749)
==23723==    by 0x4C8DF9: main (in /home/tom/bin/solver)
==23723== 
==23723== 39,232 bytes in 1 blocks are definitely lost in loss record 57 of 74
==23723==    at 0x4A0674C: operator new[](unsigned long) (vg_replace_malloc.c:305)
==23723==    by 0x2A4C6369: ???
==23723==    by 0x4C8DB7: solvermodule (in /home/tom/bin/solver)
==23723==    by 0x4C6794: MAIN__ (qdiff4v.f90:749)
==23723==    by 0x4C8DF9: main (in /home/tom/bin/solver)
==23723== 
==23723== LEAK SUMMARY:
==23723==    definitely lost: 160,336 bytes in 5 blocks
==23723==    indirectly lost: 0 bytes in 0 blocks
==23723==      possibly lost: 6,992 bytes in 23 blocks
==23723==    still reachable: 632,828,011 bytes in 73 blocks
==23723==         suppressed: 0 bytes in 0 blocks
==23723== Reachable blocks (those to which a pointer was found) are not shown.
==23723== To see them, rerun with: --leak-check=full --show-reachable=yes
==23723== 
==23723== For counts of detected and suppressed errors, rerun with: -v
==23723== ERROR SUMMARY: 7 errors from 7 contexts (suppressed: 6 from 6)

gdbによると：

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffff5a04700 (LWP 23837)]
0x00007ffff7024bc2 in ?? ()
Missing separate debuginfos, use: debuginfo-install libgcc-4.4.6-4.el6.x86_64         libgfortran-4.4.6-4.el6.x86_64 libgomp-4.4.6-4.el6.x86_64 libstdc++-4.4.6-4.el6.x86_64

これは明らかに役に立ちません。スタックサイズの問題があるかもしれないと思って、GOMP_STACKSIZEとスレッド数で遊んでいますが、役に立ちません。

何かが足りません。多分何か愚かな。そしてそれを見つけることができません。

4

1 に答える 1

0

これはGCCのバグです。openmpとiso_c_bindingモジュールの使用に関連する問題についてGCCで報告されたバグを見つけました。その後、インテル®コンパイラーを使用してコードをコンパイルして実行しましたが、問題はありませんでした。

私のコードは非常に長く、問題のある部分を特定してバグを再現し、レポートを作成する方法がわかりません。それをするために最善を尽くします。

gcc（GCC）4.4.6 20120305（Red Hat 4.4.6-4）、CentOSリリース6.3（最終版）を使用しています。

これを答えとしてマークします。後でもっと役立つものが見つかった場合は、他の人にも役立つ可能性があるため、ここに投稿します。

于 2012-12-11T09:49:43.087 に答える