ORA-600[kksfbc-reparse-infinite-loop] After applying Oracle Application patch and Working With Payables Application (Doc ID 1067839.1)

Last updated on NOVEMBER 28, 2016

Applies to:

Oracle Database - Enterprise Edition - Version 11.1.0.6 to 11.1.0.7 [Release 11.1]
Information in this document applies to any platform.
***Checked for relevance on 29-Apr-2013***

Symptoms

This problem was observed  in Oracle 11.1.0.6 on a HP-UX Itanium server.

Problem description
This is an Oracle Apps environment and the invoice function is failing.

The ALERT LOG shows internal errors which is suspected to be the source of the failures.

Errors in file /app/oracle/diag/rdbms/xxxxx/xxxxxx/trace/xxxxx_ora_19143.trc (incident=756639):
ORA-00600: internal error code, arguments: [kksfbc-reparse-infinite-loop], [0x9FFFFFFFBE50CAF8], [], [], [], [], [], []
Incident details in: /app/oracle/diag/rdbms/xxxxx/xxxxx/incident/incdir_756639/xxxxx_ora_19143_i756639.trc

Errors in file /app/oracle/diag/rdbms/xxxxxx/xxxxx/trace/xxxxx_ora_19143.trc (incident=756640):
ORA-00600: internal error code, arguments: [kxsGetRuntimeLock2], [0xC0000007BA22D878], [1], [1], [1], [], [], []
Incident details in: /app/oracle/diag/rdbms/xxxxx/xxxxxx/incident/incdir_756640/xxxxx_ora_19143_i756640.trc



The incident trace file  for the kksfbc-reparse-infinite-loop error shows a failing statement:
SELECT DISTRIBUTION_TOTAL , POSTING_FLAG , APPROVAL_STATUS_LOOKUP_CODE , PO_NUMBER ,
NOTES_COUNT , HOLDS_COUNT , AMOUNT_HOLD_FLAG , VENDOR_HOLD_FLAG , ENCUMBERED_FLAG ,
PERIOD_NAME , SELECTED_FOR_PAYMENT_FLAG , UNPOSTED_VOID_PAYMENT_FLAG ,
DISCOUNT_PAY_DISTS_FLAG , PREPAYMENTS_APPLIED_FLAG , PAYMENTS_EXIST_FLAG ,
QUERY_PACKET_ID , PREPAY_AMOUNT_APPLIED , CANCELLED_BY_DISPLAY
FROM AP_INVOICES_DERIVED_V WHERE ROW_ID = :1


The function stack shows the error occurred while finding a cursor
. .  .. . kgerinv kgeasnmierr kksfbc kkspfda kpodny kpoal8 opiodr ttcpip . . . . .

Checking the time stamp between parent and dependents, we see there are out of sync conditions.
TIMESTAMP SCRIPT
------------------
set pagesize 10000
column d_name format a20
column p_name format a20
select do.obj# d_obj,do.name d_name, do.type# d_type,
po.obj# p_obj,po.name p_name,
to_char(p_timestamp,'DD-MON-YYYY HH24:MI:SS') "P_Timestamp",
to_char(po.stime ,'DD-MON-YYYY HH24:MI:SS') "STIME",
decode(sign(po.stime-p_timestamp),0,'SAME','*DIFFER*') X
from sys.obj$ do, sys.dependency$ d, sys.obj$ po
where P_OBJ#=po.obj#(+)
and D_OBJ#=do.obj#
and do.status=1 /*dependent is valid*/
and po.status=1 /*parent is valid*/
and po.stime!=p_timestamp /*parent timestamp not match*/
order by 2,1;

D_OBJ D_NAME D_TYPE P_OBJ P_NAME P_Timestamp STIME X
---------- ------------------------------ ------- -------- ------------------------------ --------------------- --------------------- --------
311174 AP_GENERATE_DISTRIBUTIONS_PKG 11 124859 AP_APPROVAL_PKG 17-OCT-2009 14:52:03 04-FEB-2010 18:38:41 *DIFFER*
311180 AP_PMT_CALLOUT_PKG 11 124688 AP_WITHHOLDING_PKG 04-JAN-2007 07:14:23 04-FEB-2010 18:38:41 *DIFFER*
311180 AP_PMT_CALLOUT_PKG 11 108955 AP_CHECKS_PKG 17-OCT-2009 14:52:02 04-FEB-2010 18:38:42 *DIFFER*
311180 AP_PMT_CALLOUT_PKG 11 124912 AP_ACCOUNTING_EVENTS_PKG 17-OCT-2009 13:33:10 04-FEB-2010 18:38:42 *DIFFER*
311180 AP_PMT_CALLOUT_PKG 11 124851 AP_INTEREST_INVOICE_PKG 03-JAN-2007 20:17:09 04-FEB-2010 18:38:43 *DIFFER*
177486 IBY_TRXN_AMT_LMT_PKG 11 157793 IBY_UTILITY_PVT 04-DEC-2008 16:17:06 04-FEB-2010 18:38:45 *DIFFER*
311180 AP_PMT_CALLOUT_PKG 11 108945 AP_UTILITIES_PKG 17-OCT-2009 13:33:12 04-FEB-2010 18:38:45 *DIFFER*
311210 AP_PAYMENT_UTIL_PKG 11 302496 IBY_DISBURSE_UI_API_PUB_PKG 17-OCT-2009 14:52:14 04-FEB-2010 18:38:45 *DIFFER*
311210 AP_PAYMENT_UTIL_PKG 11 157793 IBY_UTILITY_PVT 17-OCT-2009 14:52:16 04-FEB-2010 18:38:45 *DIFFER*
316782 XLA_PERIOD_CLOSE_EXP_PKG 11 306745 XLA_REPORT_UTILITY_PKG 03-JAN-2007 21:31:06 04-FEB-2010 18:38:46 *DIFFER*
_$#$_
The time stamp of the changes (in this example it is Feb 2 18:38) matches the time at which the Applications patch was being installed.

To summarize, the symptoms are:
  1. Dependency time stamps are out of sync, and the time stamp change is during the period of applying an Oracle Applications patch.
  2. It is 11gR1
  3. It is an environment where objects have highly complex interdependencies (such as seen in APPS/EBusiness)
  4. Objects are recompiled after many have been invalidated (which often occurs when application patches are applied involving lots of DDL, new pl/sql source code or during major upgrades etc..)
  5. Subsequently, referencing some objects fails with errors such as ORA-6508, ORA-600 [kksfbc-reparse-infinite-loop] etc. Querying the dictionary reveals that some objects have time stamp discrepancies in dependency$.



Changes

This can happen after upgrading to 11g, and while applying patches for (or installing a new version of) Oracle Applications.

Cause

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms