|
Oracle® Application Server Forms Services Deployment Guide
10g Release 2 (10.1.2) B14032-03 |
|
 Previous |
 Next |
|
Oracle® Application Server Forms Services Deployment Guide
10g Release 2 (10.1.2) B14032-03 |
|
|
Previous |
Next |
This section contains the following:
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 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.
This section contains the following:
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.
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.
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.
