Skip Headers

Oracle® Application Server Forms Services Deployment Guide 10g Release 2 (10.1.2) B14032-03 |
| Library | Product | Contents | Index

Previous | Next |

# A.3 Diagnosing Server Crashes with Stack Traces

This section contains the following:

- Section A.3.1, "About Stack Traces"

- Section A.3.2, "Configuring and Using Stack Traces"

If the Forms web runtime terminates unexpectedly, then it writes a stack trace to the directory `ORACLE_HOME/forms/trace`. The filename will have the format `<forms_runtime_process>_dump_<process id>`.The dump file contains a stack trace of the running process, and shows the last successful operation performed by Forms.

## A.3.1 About Stack Traces

A stack trace is useful for two reasons:

- The information in the stack can be used to identify a known issue. It is not 100% reliable, but an identical stack trace is a good indicator of a matching problem. Even if it is not the same, there may be a workaround or patch for an existing bug that can be tested.

- If the problem is not a known bug, then the stack may provide valuable information to assist development efforts to pinpoint the cause.

## A.3.2 Configuring and Using Stack Traces

This section contains the following:

- Section A.3.2.1, "Verifying the Environment"

- Section A.3.2.2, "Understanding Solaris Stack Traces"

- Section A.3.2.3, "Understanding Windows Stack Traces"

### A.3.2.1 Verifying the Environment

In order to test stack tracing on UNIX or Windows you can set the environment variable `FORMS_DELIBERATECRASH`. As the name suggests, setting this will cause the forms runtime process to crash. Oracle Forms currently recognizes two settings: `1` and `2`. If FORMS_DELIBERATECRASH is set to `1` then forms will crash at runtime whenever the BELL Built-in is executed. If it is set to `2` then forms will crash at runtime whenever a when-button-pressed trigger is fired. The stack above was generated with FORMS_DELIBERATECRASH set to `2`. This environment variable can be set in the environment (for example, default.env) file.

By setting the environment variable FORMS_DELIBERATECRASH to `2`, and checking the stack trace produced against the one in this document you can determine whether the symbol files are correctly installed. Once you have confirmed that everything is working as expected, if you subsequently encounter a problem where the server has crashed, you can be sure that the stack trace will be useful in resolving the problem.

### A.3.2.2 Understanding Solaris Stack Traces

In a Solaris stack trace, the top two functions `siehjmpterm()` and `sigacthandler()` are the signal handling code - these functions will often be present in the stack trace. To see the function the program was in when the error occurred you need to read further down the stack.

### A.3.2.3 Understanding Windows Stack Traces

Stack tracing works differently on Unix and on Windows. The symbol information is contained inside the executable files and shared libraries on Unix. On Windows this information is stripped out at link time and is in the form of binary `.sym` files. There should be one .sym file for every Oracle Forms executable or DLL. The mechanism on Windows platforms is such that in the event of a crash the Forms runtime process reads all the .sym files that correspond to the forms executable files loaded into memory. It then uses the information in the .sym files to lookup the symbol name.