1. If CPU is maxing out (100%), then you may have no other choice than to kill off the sessions/processes that are consuming the high CPU.
This is normally due to spinning of the frmweb process due to returning rows from LOVs by end users that don't attempt to filter (perform blind query) in core forms.

When an end user login to forms and start working with LOV within core forms sometimes and according to the search criteria that the user will provide to filter the results in LOV, it may fetch huge numbers of records in which causes the frmweb process to grow very large, and in extreme cases this can even lock up the current process or even the whole machine.

So when executing a LOV query, every row is fetched into memory on the middle tier, the frmweb process can get extremely large, and the larger it gets the more likely it is to start paging.
Eventually it starts consuming excessive CPU just paging the process in and out of memory, which is probably what you can see here in this case as the amount of memory consumed when the LOV records are fetched into memory obviously depends on the amount of data in each record.

This has been mentioned in the following bug:
Bug 6519700 - ESC: CSE: R12SIP: 6513826 FRMWEB RUNAWAY PROCESS CONSUMING 100% CPU-MIDDLE TIER


Therefore, if the FRMWEB process is consuming near 100% CPU and sustaining this consumption, you may have to kill off the process to resume normal operation.


2. You may check the directory: $FORMS_TRACE_DIR on forms node. The FRMWEB process may create a coredump file here which may lead to clues of what caused the issue. The file is normally named: frmweb_dump_<PID>

Where PID is the process ID of the user running the form session.