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

Portrait de dinwal
dinwal
lun, 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 Haut
4 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.
Portrait de dinwal
dinwal
jeu, 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
Haut
Portrait de trbot
trbot
lun, 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).

Haut
Portrait de dinwal
dinwal
mar, 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
Haut

Connectez-vous pour laisser un commentaire.