ORA-600: [Kglhfr-bad-free] When Running UTLRP.SQL
(Doc ID 1605326.1)
Last updated on OCTOBER 02, 2019
Applies to:
Oracle Database - Enterprise Edition - Version 11.2.0.3 and laterOracle Database Exadata Cloud Machine - Version N/A and later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Oracle Database Cloud Exadata Service - Version N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Information in this document applies to any platform.
NOTE: In the images and/or the document content below, the user information and data used represents fictitious data. Any similarity to actual persons, living or dead, is purely coincidental and not intended in any manner.
Symptoms
Each time utlrp.sql is executed, it raises an ORA-600 [kglhfr-bad-free] which is reported in the alert log.
For example:
SERVER COMPONENT id=UTLRP_BGN: timestamp=2013-10-13 04:18:00
...
...
ORA-00600: internal error code, arguments: [kglhfr-bad-free], [], [], [], [], [], [], [], [], [], [], []
...
...
SERVER COMPONENT id=UTLRP_END: timestamp=2013-10-13 04:18:23
...
The trace file shows next characteristics:
========= Dump for incident 8153 (ORA 600 [kglhfr-bad-free]) ========
----- Beginning of Customized Incident Dump(s) -----
LibraryHandle: Address=0x307a52328 Hash=82696b7c LockMode=S PinMode=S LoadLockMode=X Status=VALD
ObjectName: Name=PUBLIC.<DB_LINK_NAME>@<CONNECT_STRING> <<< DBlink is being used
FullHashValue=fb78ce5a28aa5d5cad1cac0282696b7c Namespace=TABLE/PROCEDURE(01) Type=SYNONYM(05) Identifier=0 OwnerIdn=2147483644
Statistics: InvalidationCount=0 ExecutionCount=0 LoadCount=3 ActiveLocks=1 TotalLockCount=3 TotalPinCount=3
Counters: BrokenCount=1 RevocablePointer=1 KeepDependency=0 BucketInUse=5 HandleInUse=5 HandleReferenceCount=0
Concurrency: DependencyMutex=0x307a523d8(0, 8, 0, 0) Mutex=0x307a52458(1597, 115, 0, 6)
Flags=REM/PIN/TIM/[00022801] <<< Remote access
WaitersLists:
Lock=0x307a523b8[0x307a523b8,0x307a523b8]
Pin=0x307a52398[0x307a52398,0x307a52398]
LoadLock=0x307a52410[0x307a52410,0x307a52410]
Timestamp: Current=09-15-2004 18:27:08
HandleReference: Address=0x307a524e8 Handle=(nil) Flags=[00]
LibraryObject: Address=0x311ed50b0 HeapMask=0000-0000-0000-0000 Flags=EXS/LOC[0004] Flags2=LOD[0001] PublicFlags=[0000]
DataBlocks:
Block: #='0' name=KGLH0^82696b7c pins=0 Change=NONE
Heap=0x1f58b4c40 Pointer=0x311ed5150 Extent=0x311ed5030 Flags=I/-/P/A/-/-
FreedLocation=0 Alloc=1.179688 Size=3.976562 LoadTime=4882247990
Block: #='2' name=PLDIA^82696b7c pins=1 Change=NONE
Heap=0x311ed54a8 Pointer=0x30f0affa0 Extent=0x30f0aff20 Flags=I/-/P/A/-/-
FreedLocation=0 Alloc=11.671875 Size=11.929688 LoadTime=0
----- End of Customized Incident Dump(s) -----
*** 2013-10-13 04:18:05.749
dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)
----- SQL Statement (None) -----
Current SQL information unavailable - no SQL text.
----- PL/SQL Stack -----
----- PL/SQL Call Stack -----
object line object
handle number name
0x347e38500 1347 package body SYS.DBMS_UTILITY
0x341d35a08 1 anonymous block
0x341dd2d10 380 package body SYS.UTL_RECOMP
0x341dd2d10 524 package body SYS.UTL_RECOMP
0x341dd2d10 772 package body SYS.UTL_RECOMP
0x347d798f8 4 anonymous block
----- Call Stack Trace -----
skdstdst <- ksedst1 <- ksedst <- dbkedDefDump <- ksedmp <- ksfdmp <- dbgexPhaseII <- dbgexExplicitEndInc <- dbgeEndDDEInvocationImpl <- dbgeEndDDEInvocation <- kglhfr <- kqlrld <- kqlrldcu <- kqlrldop <- kqllod <- kglobld <- kglobpn <- kglpim <- kglpin <- kglgob <- qcdlgbo <- qcdlgob <- qcsfgob <- qcsprfro <- qcsprfro_tree <- qcsprfro_tree <- qcspafq <- qcspqbDescendents <- qcspqb <- qcsdrv <- qcitrans <- qcisem <- ph2csql_analyze <- ph2stm <- ph2sms <- ph2blo <- ph2obl <- ph2sbo <- ph2qcb <- ph2dcl <- ph2itm <- ph2its <- ph2blo <- ph2obl <- ph2sbo <- ph2itm <- ph2its <- ph2blo <- ph2obl <- ph2uni <- ph2dr2 <- ph2drv <- phpsem <- phpcmp <- pcicmp0 <- kkxcmp0 <- rpiswu2 <- kkxcmp <- kkpalt <- opiexe <- opiosq0 <- opiosq <- opiodr <- rpidrus <- skgmstack <- rpiswu2 <- rpidrv <- rpisplu <- kqlvld <- kglgob <- psd_validate <- pevm_icd_call_common <- pfrinstr_ICAL <- pfrrun_no_tool <- pfrrun <- plsql_run <- peicnt <- kkxexe <- opiexe <- opipls <- opiodr <- rpidrus <- skgmstack <- rpiswu2 <- rpidrv <- psddr0 <- psdnal <- pevm_EXIM <- pfrinstr_EXIM <- pfrrun_no_tool <- pfrrun <- plsql_run <- peicnt <- kkxexe <- opiexe <- kpoal8 <- opiodr <- ttcpip <- opitsk <- opiino <- opiodr <- opidrv <- sou2o <- opimai_real <- ssthrdmain <- main
The dbupgdiag.sql script as provided via
<Note 556610.1> - Script to collect DB Upgrade/Migrate Diagnostic Information
shows
- All database components are VALID and of the expected version
- The database was initially created as 8.1.7 and then via version 10.2.0.5 finally upgraded to 11.2.0.3.
- There are no Invalid SYS/SYSTEM Objects
- There was 1 (customer specific) invalid MV as shown below:
Count of Invalids by Schema
======================================================
OWNER OBJECT_TYPE COUNT(*)
------------ ---------------------------------------- ----------
...
<OWNER> MATERIALIZED VIEW 1
...
Changes
The database was initially created as 8.1.7 and then via version 10.2.0.5 finally upgraded to 11.2.0.3.
Above history was shown in the results of the dbupgdiag.sql script as provided via <Note 556610.1>
The remote database, accessed at the time of the error, was confirmed to be still Oracle8i Enterprise Edition Release 8.1.7.4.
Cause
To view full details, sign in with your My Oracle Support account. |
|
Don't have a My Oracle Support account? Click to get started! |
In this Document
Symptoms |
Changes |
Cause |
Solution |
References |