How to generate a stack trace for forms with Applications 11i - R12

Sometimes, troubleshooting forms issues such as FRM-92100, it is often useful to generate a stack trace. Steps follow to produce a stack trace for forms in 11i environment.

1. Set the following environment variables:
    a) check the value of $FORMS60_TRACE_PATH and make sure this directory has write permissions and has space.
    b) set $FORMS60_CATCHTERM=0
  
2. If your platform is Unix, check that the operating system ulimit values are sufficient.
    Run `ulimit -a` as the applmgr, assuming applmgr starts the forms server,  to check the memory, data and stack sizes.
  
3. Stop the forms server.

4. Backup file f60webmx and then relink this executable with debug symbols.
    Make sure you are signed in as the user who owns f60webmx executable, then run this command:
    adrelink.sh force=y ranlib=y link_debug=y "fnd f60webmx"
  
5. Start the forms server.
  
6. Reproduce the forms error that you are investigating.

7. Check for a new core file in the following directories:

 a) $FORMS60_TRACE_PATH directory.
or
b) check the $PWD directory for the forms server.
   By default in an Autoconfig enabled environment, this is the directory in which the adfrmctl.sh starts;
   $PWD is $COMMON_TOP/admin/scripts// directory.
  
    To confirm the $PWD directory setting, you can also check by opening any form and navigating to
         Help->Diagnostics->Examine
            In field 1 select $environment$
            In field 2 enter PWD (no $ or quotes)
           The value is populated automatically when you select the tab key.
or

c) $FND_TOP/bin directory.
  
7. If you identify a file with a corresponding timestamp to that of when the error occurs, follow
    the steps in metalink Note 1812.1 to generate a stack trace.

Follow the steps to produce a stack trace for forms in R12 environment.

Please work with the users reporting the FRM-92100 error and see if each time the issue occurs you are getting under this dir $FORMS_TRACE_DIR on forms node a file called

frmweb_dump_

Where PID is the process ID of the user running the form session.
You can ask user to identify the PID this way:
Open any form and go to Help->About Oracle Applications
You should see something like this

----------------------------------------
Forms Server
----------------------------------------
Oracle Forms Version : 10.1.2.0.2
Application Object Library : 12.0.0
Machine : R12.APPS.LOCAL
Forms User CPU (secs) : 0.363949
Forms System CPU (secs) : 0.150981
Forms Process ID : 1246

Here the form process is 1246
If the above information is not present, you need to set profile 'FND: Diagnostics' to Yes.
The process 1246 can be seen on forms node

ps -ef | grep 1246
oracle 1246 1523 0 09:55 ? 00:00:00 /oracle/VIS/apps/tech_st/10.1.2/bin/frmweb server
webfile=HTTP-0,0,1,default,192.168.100.4

as you can see there is the client IP listed 192.168.100.4 also which can be a confirmation that client is the one you expect.
If when the FRM-92101 error is raised on the client PC, please check if the process is still
running on the server

ps -ef | grep 1246

If not, please check $FORMS_TRACE_DIR for

frmweb_dump_ file and see when it's created in this case it's called frmweb_dump_1246.
If the process is dead and frmweb_dump_ file is created you need to get a core file
under the same circumstances:
1. Change FORMS_CATCHTERM=0 in $INST_TOP/ora/10.1.2/forms/server/default.env

2.Stop the services on the middle tier and relink forms executables with debug symbols on

a) cd $ORACLE_HOME/forms/lib; make -f ins_forms.mk sharedlib
b) cd $ORACLE_HOME/forms/lib; make -f ins_forms.mk install
c) adrelink.sh force=y link_debug=y "fnd fndfmxit.so"
d) adrelink.sh force=y link_debug=y "fnd fndrwxit.so"

Then start them again

On 64-bit platforms you might find ins_forms.mk file under $ORACLE_HOME/forms/lib32 directory instead.

3. Confirm in any forms session that changes have taken effect by going to
Help->Diagnostics->Examine
In 'Block' field enter $ENVIRONMENT$
In 'Field' field enter FORMS_CATCHTERM and hit tab.
In the 'Value' field you will see the value and this value should be 0

The purpose of all these steps is to generate a core dump file. If FORMS_CATCHTERM is set to 1 no core dump is generated, and instead you get a text frmweb_dump_ in $FORMS_TRACE_DIR without much infrmation. If FORMS_CATCHTERM is set to 0 a binary core dump file will be generated either under $FORMS_TRACE_DIR or under PWD dir. You can find the PWD directory this way.

Open any form and go to Help->Diagnostics->Examine
In 'Block' field enter $ENVIRONMENT$
In 'Field' field enter PWD and hit tab.
In the 'Value' field you will see the value where core dump file is generated.

4.Once this core dump is generated (look for a file named core, a simple ls *core* under PWD or $FORMS_TRACE_DIR will be enough) we can use it to get a stack trace as per Note 1812.1. This stack trace should be the one you upload in the TAR so we can see whether you are facing some known bug due to which forms process crashes. Try to see if there is a pattern with all forms processes that crash.

Related Posts by Categories