ошибка сегментации при выходе из кода openmp

У меня есть код CPP, который использует openmp. Он связан с кодом fortran90. Если вы используете один поток, все в порядке. Если вы работаете с любым количеством потоков, отличных от 1, я получаю ошибку сегментации при выходе из части cpp. Результат кода является точным, никаких ошибок вообще. Он работает гладко, пока не придет время для выхода. Часть кода, связанная с openmp, составляет:ошибка сегментации при выходе из кода 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: [email protected]@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 и количеством потоков, , думая, что у меня может быть проблема с размером стека, но безрезультатно.

Мне что-то не хватает. Может быть, что-то глупое. И не может найти его.

источник

2012-12-04 cauchy

'valgrind' часто дает ложные срабатывания с программами OpenMP. Когда вы запускаете «OMP_NUM_THREADS = 1», параллельная область вообще не активируется и не создаются нити OpenMP. Как вы связываете свою программу? –

Код C++ - это общая библиотека, которая вызывается из модуля fortran, который использует модуль iso_c_binding. – cauchy

'0x00007ffff7024bc2 in ??() '- адрес стека. Это может означать, что обратный адрес от какого-либо вызова функции был перезаписан значением указателя (для переменной стека). Я не могу сказать больше, учитывая количество кода, представленного здесь. –

Это ошибка в GCC. Я обнаружил ошибку, сообщенную о GCC, о проблемах, связанных с использованием openmp и модуля iso_c_binding. После этого я скомпилировал и выполнил код с помощью компилятора Intel без каких-либо проблем.

Мой код довольно длинный и не имеет понятия, как изолировать проблематичную часть, чтобы воспроизвести ошибку и сделать отчет. Сделаю все возможное, чтобы сделать это.

Я использую gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4), выпуск CentOS 6.3 (Final).

Я отмечу это как ответ, и если я найду что-нибудь полезнее позже, я отправлю его здесь, потому что он может быть полезен другим.

источник

2012-12-11 09:49:43 cauchy

Не могли бы вы разместите ссылку на отчет gcc bug? –

ошибка сегментации при выходе из кода openmp

ответ

Смежные вопросы