APPLIES TO:
Oracle E-Business Suite Technology Stack - Version 12.0 to 12.2 [Release 12.0 to 12.2]Information in this document applies to any platform.
Checked for relevance on 08-Aug-2017
GOAL
When troubleshooting forms issues such as FRM-92100, it is often useful to generate a stack trace. Support will often request for a stack trace generated from a core file.
Under what circumstances this stack trace is created and how to generate this stack trace?
Under what circumstances this stack trace is created and how to generate this stack trace?
SOLUTION
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_<PID>
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 : TESTRO15.RO.ORACLE.COM
Forms User CPU (secs) : 0.333949
Forms System CPU (secs) : 0.120981
Forms Process ID : 29246
Here the form process is 29246
If the above information is not present, you need to set profile 'FND: Diagnostics' to Yes.
The process 29246 can be seen on forms node
ps -ef | grep 29246
oracle 29246 20523 0 11:55 ? 00:00:00 /oracle/VIS/apps/tech_st/10.1.2/bin/frmweb server
webfile=HTTP-0,0,1,default,10.171.114.234
as you can see there is the client IP listed 10.171.114.234 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 29246
If not, please check $FORMS_TRACE_DIR for frmweb_dump_<PID> file and see when it's created in this case it's called frmweb_dump_29246.
If the process is dead and frmweb_dump_<PID> file is created you need to get a core file under the same circumstances:
1. Change FORMS_CATCHTERM=1 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 1
The purpose of all these steps is to generate a core dump file. If FORMS_CATCHTERM is set to 0 no core dump is generated, and instead you get a text frmweb_dump_<PID> in $FORMS_TRACE_DIR without much information. If FORMS_CATCHTERM is set to 1 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.
For 11i, please look at Note 353805.1
5. Turn off debug. Do the following to remove debug symbols:
a) adrelink.sh force=y "fnd fndfmxit.so"
b) adrelink.sh force=y "fnd fndrwxit.so"
frmweb_dump_<PID>
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 : TESTRO15.RO.ORACLE.COM
Forms User CPU (secs) : 0.333949
Forms System CPU (secs) : 0.120981
Forms Process ID : 29246
Here the form process is 29246
If the above information is not present, you need to set profile 'FND: Diagnostics' to Yes.
The process 29246 can be seen on forms node
ps -ef | grep 29246
oracle 29246 20523 0 11:55 ? 00:00:00 /oracle/VIS/apps/tech_st/10.1.2/bin/frmweb server
webfile=HTTP-0,0,1,default,10.171.114.234
as you can see there is the client IP listed 10.171.114.234 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 29246
If not, please check $FORMS_TRACE_DIR for frmweb_dump_<PID> file and see when it's created in this case it's called frmweb_dump_29246.
If the process is dead and frmweb_dump_<PID> file is created you need to get a core file under the same circumstances:
1. Change FORMS_CATCHTERM=1 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 1
The purpose of all these steps is to generate a core dump file. If FORMS_CATCHTERM is set to 0 no core dump is generated, and instead you get a text frmweb_dump_<PID> in $FORMS_TRACE_DIR without much information. If FORMS_CATCHTERM is set to 1 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.
For 11i, please look at Note 353805.1
5. Turn off debug. Do the following to remove debug symbols:
a) adrelink.sh force=y "fnd fndfmxit.so"
b) adrelink.sh force=y "fnd fndrwxit.so"
REFERENCES
NOTE:1812.1 - TECH: Getting a Stack Trace from a CORE file on UnixNOTE:353805.1 - How To Generate A Stack Trace For Forms With Applications 11i?
No comments:
Post a Comment