Seg fault with -O0 or -O1 flag but not with -O2 or -O3

Seg fault with -O0 or -O1 flag but not with -O2 or -O3

Bild des Benutzers dinwal
dinwal
Mo, 28/02/2011 - 18:26

I have a strange issue with an embarrasingly parallel code.When I run it with -O0 or -O1 optimization flags my code throws segfault. However, with -O2 or -O3 flag it runs just fine. The debugger (gdb) says the error is at a OpenMP parallel for directive. I would appreciate if someone has an idea as to what could be the possible reason. I am also debugging in the meantime and will post if I find something. Thank you.

Dinesh Agarwal
RSS Oben
4 Beiträge / 0 neu
Letzter Beitrag
Nähere Informationen zur Compiler-Optimierung finden Sie in unserem Optimierungshinweis.
Bild des Benutzers dinwal
  • Zum Verfassen von Kommentaren bitte anmelden.
dinwal
Do, 03/03/2011 - 10:31

I figured out the reason for segfault but I am still not sure why the behavior was different for different optimization flags. The reason for segfault was missing a variable in the list of private variables for the OMP parallel for directive.

Dinesh Agarwal
Oben
Bild des Benutzers trbot
  • Zum Verfassen von Kommentaren bitte anmelden.
trbot
Mo, 14/03/2011 - 00:50

I've seen this fairly often when writing sequential C++ code. I figure the optimization re-arranges memory accesses in a way that happens to expose the segmentation fault. (A non-allocated region of memory may never be touched, so these bugs go undetected frequently; in this case, my claim is that certain optimizations are simply re-shuffling accesses in a way that exposes the bug.) On a side-note, I always try to run my software through a memory checker like valgrind to make sure I don't have any silent seg-faults waiting to happen (that my code hasn't happened to trigger yet).

Oben
Bild des Benutzers dinwal
  • Zum Verfassen von Kommentaren bitte anmelden.
dinwal
Di, 15/03/2011 - 10:54
Quoting trbot I've seen this fairly often when writing sequential C++ code. I figure the optimization re-arranges memory accesses in a way that happens to expose the segmentation fault. (A non-allocated region of memory may never be touched, so these bugs go undetected frequently; in this case, my claim is that certain optimizations are simply re-shuffling accesses in a way that exposes the bug.) On a side-note, I always try to run my software through a memory checker like valgrind to make sure I don't have any silent seg-faults waiting to happen (that my code hasn't happened to trigger yet).

That is a very valid point. I second you on the point about Valgrind. An application must pass valgrind (at least --tool=memcheck) with 0 errors, It applies for warnings with -Wall option for gcc flag as well.

Dinesh Agarwal
Oben

Melden Sie sich an, um einen Kommentar zu hinterlassen.