- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi,
I have a code which uses the PETSc library. When optimization is turned off, the code runs fine. However, when I turn on optimization, I got:
[0]PETSC ERROR: ------------------------------------------------------------------------
[0]PETSC ERROR: Caught signal number 11 SEGV: Segmentation Violation, probably memory access out of range
...
After some search, I found that if I only use -O1 in one of the source code (others still using -ip -O3 -ipo), the code runs fine.
The error seems to happen after calling a PETSc subroutine. However, this subroutine was also called in other source codes but it runs fine with optimization.
So is this a bug with the optimization routine? Or is there some error in the PETsc subroutine?
Please advise. Thanks!
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It would help if you state the version number of IVF with your problem.
Have you built the program in Debug build including all tests (in particular undefined variables, and argument checking).
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Jim,
Thanks for the help. I'm using the 2016.1.150 ver. For the debug build, I use:
-fpe0 -gen-interfaces -warn interfaces -traceback -g -debug all -implicitnone -warn unused -fp-stack-check -heap-arrays -ftrapuv -check pointers -O0 -save -w90 -w -w95
Is this enough?
I also just tried a new build on my cluster - 2017.0.098 ver. Strangely, using the same option (only use -O1 in one of the source code, others still using -ip -O3 -ipo), the code still gives segmentation fault. Only the debug build works. However, I haven't tried switching off the optimized option one by one for each source code for the 2017.0.098 ver.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The options you used should have caught most program call/interface issues.
Try -O3 without inter-file IPO (intra file is OK for first test)
Then -O3 without any IPO
Then disable -O3 on a file by file basis (if you have a lot of files you can perform a quazi-binary search).
There were reports of some vectorization issues on some nested loops.
Are you using a 3rd party library?
In this case, the interface could be undefined and the compiler would have no way to verify arguments. If you make a call with incorrect arguments then this may trigger the error.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks Jim,
Based on ver 2016.1.150, I found that one file can only use -O1, without -ip and -ipo. For other files, I use -O3 -ip and -ipo.
So is this the best solution, assuming there's no error with any argument.?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, I have a few programs that I must disable IPO, and in some cases O2 or O3. One of the facts of life with living in an imperfect world.
Jim Dempsey

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page