HP Fortran Programmer Guide (766160-001, March 2014)

See the HPFortran Programmer’s Reference, for detailed information about the +FPand
+fp_exceptionoptions. Also, the HP-UX Floating-Point Guide has a useful discussion of both
options and includes detailed information on floating-point exceptions and how to handle them.
Illegal instruction exception
An illegal instruction exception occurs when a program attempts to execute a bit pattern that is
not an op-code. A common cause of this exception is an overwritten stack. If a program overwrites
the part of the stack that holds the return address, the new (and bad) address may cause execution
control to jump to a memory location that contains data or some other nonexecutable bit pattern.
The attempt to execute this location will result in an illegal instruction exception.
This exception can also occur if your program is linked to a bad library, especially if the library
contains code that was written in assembler or if it was corrupted during a file transfer.
This exception may indicate a compiler error. If you cannot find the cause of this exception in your
code, contact your HP support representative.
Segmentation violation exception
Before a program starts to execute, it is allocated a memory segment, which defines the area of
memory that it can use. If the program attempts to access a memory location outside its segment,
the operating system will raise the SIGSEGVsignal, indicating a segmentation violation or memory
fault.
Any program that can generate address references outside its segment—for example, by indexing
beyond the declared boundary of an array—may cause a segmentation violation. In C programs,
bad pointers often result in this exception. The standard Fortran90 pointer is more self-protective
than the C pointer, but it too can be misused and lead to the state of mind memorialized in the
lyric (known only to Cooper Redwine1): “I’ve got those segmentation violation, core dumped
blues.” The Cray-style pointer extension is more like the C pointer and is therefore more susceptible
to the abuse that results in segmentation violations.
Programs that cause a stack overflow (for example, by attempting to allocate more local variables
on the stack than the kernel can handle or by infinite recursion) can also cause a segmentation
violation. If your program needs a bigger stack, run the System Administrator Manager (SAM)
and increase the maxssiz parameter. Also, see the HP-UX System Administration Tasks manual for
information about reconfiguring the kernel.
Segmentation violations are especially common when calling C functions from Fortran program
units. If the number, type, or calling conventions of the arguments being passed do not match, the
call is likely to result in an exception. For example, if you use the built-in function %VAL to declare
an argument as passed by value, but the C function is expecting a pointer, a segmentation violation
may occur. (%VAL and %REF are HPFortran extensions; for information about using them when
calling a C routine from Fortran, see “Argument-passing conventions” (page 113).)
In most cases, debugging requires locating the code that caused the segmentation violation and
rewriting it. If your program aborts with this error, recompile it with the +fp_exceptionoption.
A program compiled with this option will display a procedure traceback when it aborts. The
procedure traceback lists procedure names and offset addresses of the code that caused the
exception.
If you suspect that an out-of-bounds array reference is causing the segmentation violation, you can
use the +check=alloption instead of the +fp_exceptionoption. When compiled with the
+check=all option, a program that attempts to reference an array element that is outside the
declared array boundary will abort with an error message that gives the line number of where the
reference was detected.
The +check=allalso performs runtime checks for out-of-bounds substrings and for integer overflow;
see “Calling a trap procedure” (page 84). The +check option is fully described in the HPFortran
Programmer’s Reference.
Handling runtime exceptions 79