ORA-07445: 出現異常錯誤: 核心轉儲 [plcurClose()+40] [SIGSEGV]
1.環境介紹
DB版本：Oracle 11g 11.2.0.3 64位
OS版本: IBM AIX 6.1 64位
2.現象
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x424C455F51545A0C] [PC:0x102618AA8, plcurClose()+40] [flags: 0x0, count: 1]
Errors in file /u01/oracle/diag/rdbms/jzh/jzh2/trace/jzh2_j012_6095470.trc (incident=492774):
ORA-07445: 鍑虹幇寮傚父閿欒?: 鏍稿績杞?偍 [plcurClose()+40] [SIGSEGV] [ADDR:0x424C455F51545A0C] [PC:0x102618AA8] [Address not mapped to object] []
Incident details in: /u01/oracle/diag/rdbms/jzh/jzh2/incident/incdir_492774/jzh2_j012_6095470_i492774.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
其實從標紅字型大概可以看出是與plsql,cursor close有關，也就是在plsql塊中關閉遊標有關，接下檢視jzh2_j012_6095470_i492774.trc檔案內容：
Dump continued from file: /u01/oracle/diag/rdbms/jzh/jzh2/trace/jzh2_j012_6095470.trc
ORA-07445: 出現異常錯誤: 核心轉儲 [plcurClose()+40] [SIGSEGV] [ADDR:0x424C455F51545A0C] [PC:0x102618AA8] [Address not mapped to object] []
========= Dump for incident 492774 (ORA 7445 [plcurClose()+40]) ========
----- Beginning of Customized Incident Dump(s) -----
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x424C455F51545A0C] [PC:0x102618AA8, plcurClose()+40] [flags: 0x0, count: 1]
Registers:
iar: 0x0000000102618aa8 lr: 0x0000000101ba9bb0
msr: 0xa00000000200d032 cr: 0x0000000042242048
r00: 0x0000000000000011 r01: 0x0fffffffffffc0e0 r02: 0x00000001106597d8
r03: 0x0000000110000250 r04: 0x0000000000000020 r05: 0x0000000000000011
r06: 0x0000000000000011 r07: 0x424c455f5154592c r08: 0x0000000110a82a68
r09: 0x0000000000000000 r10: 0x0700001b6f6910e8 r11: 0x0000000000000000
r12: 0x0000000048248044 r13: 0x00000001106cbc00 r14: 0x0000000000000001
r15: 0x0ffffffffffff578 r16: 0x0ffffffffffff588 r17: 0x0800200140000000
r18: 0x0ffffffffffffed0 r19: 0x0000000000000000 r20: 0x0000000000000000
r21: 0x0000000109d5aba8 r22: 0x0000000110bbeb98 r23: 0x0000000000000000
r24: 0x0000000110878e88 r25: 0x0000000110878f30 r26: 0x0000000110dd9a70
r27: 0x0000000000000028 r28: 0x0000000000000028 r29: 0x0000000000000012
r30: 0x00000012000200eb r31: 0x0000000110b97908
*** 2014-12-26 16:02:35.800
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x3, level=3, mask=0x0)
----- SQL Statement (None) -----
Current SQL information unavailable - no cursor.
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
skdstdst()+40 bl 107c4a874 000000000 ? 000000001 ?
000000003 ? 000000001 ?
000000000 ? 000000001 ?
000000003 ? 000000001 ?
ksedst1()+112 call skdstdst() 13B35D5BA86695DA ?
4824384100000000 ?
110844E30 ? 000002004 ?
1106CFD00 ? 10A389A84 ?
000000000 ? 1106CFD00 ?
ksedst()+40 call ksedst1() 30300000000 ? 002050033 ?
10A389A78 ? 7000000000262 ?
000000000 ? 000000000 ?
10A389078 ? 000000000 ?
dbkedDefDump()+1516 call ksedst() 000000005 ? 110000B14 ?
000000000 ? 110000B14 ?
E000000000000000 ?
000000000 ? 000000000 ?
300000003 ?
ksedmp()+72 call dbkedDefDump() 300000000 ? 030623937 ?
102618AA8 ? 000000001 ?
00000000B ? 110845B10 ?
110845DC0 ? 000000001 ?
ssexhd()+2672 call ksedmp() 109E0CBF0 ? 200000002 ?
000000004 ? 000000000 ?
000000004 ? 000000001 ?
073652829 ? 000000004 ?
48bc call ssexhd() 000000000 ? 000000000 ?
000000000 ? 000000000 ?
000000000 ? 000000000 ?
000000000 ? 000000000 ?
kgscReleaseACursor( call 48bc 700001AE12B25F8 ? 000000000 ?
)+716 FFFFFFFFFFFC550 ?
700001A0BA36A10 ?
FFFFFFFFFFFFFFFF ?
10B0B0448 ? 000000001 ?
000000001 ?
kgscReleaseCursorGr call kgscReleaseACursor( FFFFFFFFFFFC550 ? 000057E40 ?
oup()+288 ) 110A82A68 ? 110BBEB98 ?
12000200EB ? 2C00000028 ?
FFFFFFFFFFFC560 ?
FFFFFFFFFFFC470 ?
標紅字型就是釋放遊標的地方，也就是出錯的地方，接著往下看：
========== FRAME [7] (48bc -> ssexhd()) ==========
defined by frame pointers 0xfffffffffffc330 and 0x110845aa0
CALL TYPE: call ERROR SIGNALED: yes COMPONENT: (null)
Dump of memory from 0xfffffffffffc330 to 0xfffffffffffc730
FFFFFFFFFFFC330 0FFFFFFF FFFFC400 0FFFFFFF FFFFC200 [................]
FFFFFFFFFFFC340 00000001 01BA9BB0 00000001 106CBC00 [.............l..]
FFFFFFFFFFFC350 0FFFFFFF FFFFC430 00000001 106597D8 [.......0.....e..]
FFFFFFFFFFFC360 0700001A E12B25F8 00000000 00000000 [.....+%.........]
FFFFFFFFFFFC370 0FFFFFFF FFFFC550 0700001A 0BA36A10 [.......P......j.]
FFFFFFFFFFFC380 FFFFFFFF FFFFFFFF 00000001 0B0B0448 [...............H]
FFFFFFFFFFFC390 00000000 00000001 00000000 00000001 [................]
FFFFFFFFFFFC3A0 0700001A 0BA36A08 00000000 00000000 [......j.........]
FFFFFFFFFFFC3B0 00000001 09D5ABA8 00000000 00000000 [................]
FFFFFFFFFFFC3C0 00000000 00000B22 07000000 00003668 [......."......6h]
FFFFFFFFFFFC3D0 00000001 10000218 00000001 10BBEBC0 [................]
FFFFFFFFFFFC3E0 00000000 00000028 00000000 00000003 [.......(........]
FFFFFFFFFFFC3F0 00000000 00000000 00000001 10A6FA60 [...............`]
FFFFFFFFFFFC400 0FFFFFFF FFFFC4B0 00000000 00000000 [................]
FFFFFFFFFFFC410 00000001 01BA9884 00000001 10000250 [...............P]
FFFFFFFFFFFC420 00000000 00002000 00000000 00072000 [...... ....... .]
FFFFFFFFFFFC430 0FFFFFFF FFFFC550 00000000 00057E40 [.......P......~@]
FFFFFFFFFFFC440 00000001 10A82A68 00000001 10BBEB98 [......*h........]
FFFFFFFFFFFC450 00000012 000200EB 0000002C 00000028 [...........,...(]
FFFFFFFFFFFC460 0FFFFFFF FFFFC560 0FFFFFFF FFFFC470 [.......`.......p]
從標紅字型來看，證明了上面的判斷是對的，該錯誤是由於在 plsql中釋放遊標的出現的錯誤。
mos上找到一篇文章解釋如下：
Information in this document applies to any platform.
From the trace, it can be identified if the process was deleted and that the error was reported at cleanup by seeing the DEL flag:
Review of the generated tracefiles reveals a call stack similar to:
closed as a duplicate of
Unpublished Bug:11786776 HIT ORA-07445 [PLCURCLOSE()+27] WHEN RUNNING MIXED WORKLOAD
這是一個bug，bug號是11786776，在11.2.0.4中得到修復，詳細見 文件 ID 11786776.8。
DB版本：Oracle 11g 11.2.0.3 64位
OS版本: IBM AIX 6.1 64位
2.現象
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x424C455F51545A0C] [PC:0x102618AA8, plcurClose()+40] [flags: 0x0, count: 1]
Errors in file /u01/oracle/diag/rdbms/jzh/jzh2/trace/jzh2_j012_6095470.trc (incident=492774):
ORA-07445: 鍑虹幇寮傚父閿欒?: 鏍稿績杞?偍 [plcurClose()+40] [SIGSEGV] [ADDR:0x424C455F51545A0C] [PC:0x102618AA8] [Address not mapped to object] []
Incident details in: /u01/oracle/diag/rdbms/jzh/jzh2/incident/incdir_492774/jzh2_j012_6095470_i492774.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
其實從標紅字型大概可以看出是與plsql,cursor close有關，也就是在plsql塊中關閉遊標有關，接下檢視jzh2_j012_6095470_i492774.trc檔案內容：
Dump continued from file: /u01/oracle/diag/rdbms/jzh/jzh2/trace/jzh2_j012_6095470.trc
ORA-07445: 出現異常錯誤: 核心轉儲 [plcurClose()+40] [SIGSEGV] [ADDR:0x424C455F51545A0C] [PC:0x102618AA8] [Address not mapped to object] []
========= Dump for incident 492774 (ORA 7445 [plcurClose()+40]) ========
----- Beginning of Customized Incident Dump(s) -----
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0x424C455F51545A0C] [PC:0x102618AA8, plcurClose()+40] [flags: 0x0, count: 1]
Registers:
iar: 0x0000000102618aa8 lr: 0x0000000101ba9bb0
msr: 0xa00000000200d032 cr: 0x0000000042242048
r00: 0x0000000000000011 r01: 0x0fffffffffffc0e0 r02: 0x00000001106597d8
r03: 0x0000000110000250 r04: 0x0000000000000020 r05: 0x0000000000000011
r06: 0x0000000000000011 r07: 0x424c455f5154592c r08: 0x0000000110a82a68
r09: 0x0000000000000000 r10: 0x0700001b6f6910e8 r11: 0x0000000000000000
r12: 0x0000000048248044 r13: 0x00000001106cbc00 r14: 0x0000000000000001
r15: 0x0ffffffffffff578 r16: 0x0ffffffffffff588 r17: 0x0800200140000000
r18: 0x0ffffffffffffed0 r19: 0x0000000000000000 r20: 0x0000000000000000
r21: 0x0000000109d5aba8 r22: 0x0000000110bbeb98 r23: 0x0000000000000000
r24: 0x0000000110878e88 r25: 0x0000000110878f30 r26: 0x0000000110dd9a70
r27: 0x0000000000000028 r28: 0x0000000000000028 r29: 0x0000000000000012
r30: 0x00000012000200eb r31: 0x0000000110b97908
*** 2014-12-26 16:02:35.800
dbkedDefDump(): Starting a non-incident diagnostic dump (flags=0x3, level=3, mask=0x0)
----- SQL Statement (None) -----
Current SQL information unavailable - no cursor.
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
skdstdst()+40 bl 107c4a874 000000000 ? 000000001 ?
000000003 ? 000000001 ?
000000000 ? 000000001 ?
000000003 ? 000000001 ?
ksedst1()+112 call skdstdst() 13B35D5BA86695DA ?
4824384100000000 ?
110844E30 ? 000002004 ?
1106CFD00 ? 10A389A84 ?
000000000 ? 1106CFD00 ?
ksedst()+40 call ksedst1() 30300000000 ? 002050033 ?
10A389A78 ? 7000000000262 ?
000000000 ? 000000000 ?
10A389078 ? 000000000 ?
dbkedDefDump()+1516 call ksedst() 000000005 ? 110000B14 ?
000000000 ? 110000B14 ?
E000000000000000 ?
000000000 ? 000000000 ?
300000003 ?
ksedmp()+72 call dbkedDefDump() 300000000 ? 030623937 ?
102618AA8 ? 000000001 ?
00000000B ? 110845B10 ?
110845DC0 ? 000000001 ?
ssexhd()+2672 call ksedmp() 109E0CBF0 ? 200000002 ?
000000004 ? 000000000 ?
000000004 ? 000000001 ?
073652829 ? 000000004 ?
48bc call ssexhd() 000000000 ? 000000000 ?
000000000 ? 000000000 ?
000000000 ? 000000000 ?
000000000 ? 000000000 ?
kgscReleaseACursor( call 48bc 700001AE12B25F8 ? 000000000 ?
)+716 FFFFFFFFFFFC550 ?
700001A0BA36A10 ?
FFFFFFFFFFFFFFFF ?
10B0B0448 ? 000000001 ?
000000001 ?
kgscReleaseCursorGr call kgscReleaseACursor( FFFFFFFFFFFC550 ? 000057E40 ?
oup()+288 ) 110A82A68 ? 110BBEB98 ?
12000200EB ? 2C00000028 ?
FFFFFFFFFFFC560 ?
FFFFFFFFFFFC470 ?
標紅字型就是釋放遊標的地方，也就是出錯的地方，接著往下看：
========== FRAME [7] (48bc -> ssexhd()) ==========
defined by frame pointers 0xfffffffffffc330 and 0x110845aa0
CALL TYPE: call ERROR SIGNALED: yes COMPONENT: (null)
Dump of memory from 0xfffffffffffc330 to 0xfffffffffffc730
FFFFFFFFFFFC330 0FFFFFFF FFFFC400 0FFFFFFF FFFFC200 [................]
FFFFFFFFFFFC340 00000001 01BA9BB0 00000001 106CBC00 [.............l..]
FFFFFFFFFFFC350 0FFFFFFF FFFFC430 00000001 106597D8 [.......0.....e..]
FFFFFFFFFFFC360 0700001A E12B25F8 00000000 00000000 [.....+%.........]
FFFFFFFFFFFC370 0FFFFFFF FFFFC550 0700001A 0BA36A10 [.......P......j.]
FFFFFFFFFFFC380 FFFFFFFF FFFFFFFF 00000001 0B0B0448 [...............H]
FFFFFFFFFFFC390 00000000 00000001 00000000 00000001 [................]
FFFFFFFFFFFC3A0 0700001A 0BA36A08 00000000 00000000 [......j.........]
FFFFFFFFFFFC3B0 00000001 09D5ABA8 00000000 00000000 [................]
FFFFFFFFFFFC3C0 00000000 00000B22 07000000 00003668 [......."......6h]
FFFFFFFFFFFC3D0 00000001 10000218 00000001 10BBEBC0 [................]
FFFFFFFFFFFC3E0 00000000 00000028 00000000 00000003 [.......(........]
FFFFFFFFFFFC3F0 00000000 00000000 00000001 10A6FA60 [...............`]
FFFFFFFFFFFC400 0FFFFFFF FFFFC4B0 00000000 00000000 [................]
FFFFFFFFFFFC410 00000001 01BA9884 00000001 10000250 [...............P]
FFFFFFFFFFFC420 00000000 00002000 00000000 00072000 [...... ....... .]
FFFFFFFFFFFC430 0FFFFFFF FFFFC550 00000000 00057E40 [.......P......~@]
FFFFFFFFFFFC440 00000001 10A82A68 00000001 10BBEB98 [......*h........]
FFFFFFFFFFFC450 00000012 000200EB 0000002C 00000028 [...........,...(]
FFFFFFFFFFFC460 0FFFFFFF FFFFC560 0FFFFFFF FFFFC470 [.......`.......p]
從標紅字型來看，證明了上面的判斷是對的，該錯誤是由於在 plsql中釋放遊標的出現的錯誤。
mos上找到一篇文章解釋如下：
APPLIES TO:
Oracle Database - Enterprise Edition - Version 11.2.0.2.0 and laterInformation in this document applies to any platform.
SYMPTOMS
Processes that have run PLSQL blocks may fail at session cleanup with:
ORA-07445: exception encountered: core dump [plcurClose()+24] [SIGBUS] [ADDR:0xDF] [PC:0x108C070F8] [Invalid address alignment] []
From the trace, it can be identified if the process was deleted and that the error was reported at cleanup by seeing the DEL flag:
flags: (0x8000041) USR/- flags_idl: (0x21) BSY/-/-/DEL/-/-
Review of the generated tracefiles reveals a call stack similar to:
plcurClose
CAUSE
This is due to - ORA-07445 [PLCURCLOSE()+24] AT SESSION CLEANUPclosed as a duplicate of
Unpublished Bug:11786776 HIT ORA-07445 [PLCURCLOSE()+27] WHEN RUNNING MIXED WORKLOAD
SOLUTION
Apply LNX64-RAC HIT ORA-07445 [PLCURCLOSE()+27] WHEN RUNNING MIXED WORKLOAD if available for your version and platform.
If the patch is not available on the My Oracle Support portal, open a Service Request with Oracle Support asking for a patch providing the relevant traces and justifications.
這是一個bug，bug號是11786776，在11.2.0.4中得到修復，詳細見 文件 ID 11786776.8。
來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/10271187/viewspace-1415141/，如需轉載，請註明出處，否則將追究法律責任。
相關文章
- ORA-07445: 出現異常錯誤: 核心轉儲 [ldxsnf()+625] [SIGSEGVGse
- ORA-07445 : 出現異常錯誤: 核心轉儲
- ORA-07445 : 出現異常錯誤: 核心轉儲(一)
- ORA-07445: 出現異常錯誤: 核心轉儲 [kkqstcrf()+1355]CRF
- ORA-07445: 出現異常錯誤: 核心轉儲 [kcbs_simulate()+5112]
- ORA-07445:出現異常錯誤:核心轉儲[kkqfppDrv1()+101]Address not mapped to objectAPPObject
- Oracle內部錯誤:ORA-07445[_memcpy()+52] [SIGSEGV]一例OraclememcpyGse
- ORA-07445異常報錯opixguid()+13GUI
- Ubuntu20.04出現段錯誤核心已轉儲問題解決方案Ubuntu
- ORACLE 異常錯誤 錯誤號大全Oracle
- PHP錯誤和異常PHP
- PHP 核心知識點（一）異常和錯誤處理PHP
- 10.2.0.1資料庫exp出現Ora-07445錯誤資料庫
- 異常錯誤資訊處理
- python錯誤與異常Python
- Flutter之異常和錯誤Flutter
- Oracle異常錯誤處理Oracle
- ORACLE 異常錯誤處理Oracle
- php錯誤及異常捕捉PHP
- 經常出現 HTTP Status 500 -錯誤HTTP
- 錯誤和異常 (一)：錯誤基礎知識
- Struts+Hibernate+Spring出現異常錯誤，高手指點，謝謝！Spring
- Swift 中的錯誤與異常Swift
- ORA-07445錯誤分析
- 報錯：ORA-07445: exception encountered: core dump [kkqtnloCbk()+111] [SIGSEGV]ExceptionQTGse
- web前端之異常/錯誤監控Web前端
- php錯誤與異常處理方法PHP
- goang 錯誤&異常處理機制Go
- C++錯誤和異常處理C++
- Laravel Exceptions——異常與錯誤處理LaravelException
- web前端小白經常出現“四”個錯誤Web前端
- postfix時常提示出現關於set-uid的錯誤(轉)UI
- 利用異常表處理Linux核心態缺頁異常(轉)Linux
- 利用script的異常處理避免網頁出錯 (轉)網頁
- 淺析php中的異常與錯誤PHP
- Golang 學習筆記八 錯誤異常Golang筆記
- [python官方文件]8錯誤和異常Python
- 總結:整理 oracle異常錯誤處理 .Oracle