But I did need to find a workaround for the problem. So I set out to study the dump trace to see what I can find. Here is a excerpt of dump trace:
ORA-07445: exception encountered: core dump [lxhasc()+20] [SIGSEGV] [Address not mapped to object] [0x000000060] [] []
Current SQL statement for this session:
SELECT T.LOGIN_TOKEN_ID, T.TOKEN_EFFECTIVE_DT, S.SUSPENDED_FL FROM XE_LOGIN_TOKEN T, XE_LOGIN S WHERE (1=1) AND S.SESSION_START_DT = TRUNC(SYSDATE) AND S.IP_NM = :B2 AND S.LEGAL_ENTITY_ID = ( SELECT LEGAL_ENTITY_ID FROM XE_LEGAL_ENTITY WHERE USER_NM = :B3 AND PRIVILEGE_CD <> 16384 AND LENTITY_STATUS_CD <> 'IN' ) AND T.LOGIN_ID = S.LOGIN_ID AND T.TOKEN_TXT = :B1
----- PL/SQL Call Stack -----
object line object
handle number name
47b652a18 1093 package body abc.login_pg
47b65be78 1 anonymous block
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
-------------------- -------- -------------------- ----------------------------
ksedmp()+744 CALL ksedst() 000000780 ? 10608E2AC ?
000000000 ? 10608ADA0 ?
106089B08 ? 10608A508 ?
ssexhd()+1240 CALL ksedmp() 000105C00 ? 105F0CD24 ?
105F0C000 ? 000105F0C ?
000105C00 ? 105F0CD24 ?
sigacthandler()+44 PTR_CALL 0000000000000000 105F0A000 ? 106091EF0 ?
105F06CEC ? 000105F0A ?
00000000B ? 000000067 ?
lxhasc()+20 PTR_CALL 0000000000000000 00000000B ? 106091EF0 ?
106091C10 ? 000000014 ?
FFFFFFFF7AA2BE58 ?
105F1C618 ?
ldxsnf()+76 FRM_LESS lxhasc() FFFFFFFF7ADABA70 ?
105F1C598 ? 000000007 ?
000000014 ?
FFFFFFFF7AA2BE58 ?
105F1C618 ?
ldxgpc()+56 CALL ldxsnf() 105F16F28 ?
FFFFFFFF7FFF4FD8 ?
FFFFFFFF7FFF4FD0 ?
FFFFFFFF7FFF4FC8 ?
FFFFFFFF7ADABA70 ?
FFFFFFFF7FFF4DA0 ?
evadrn()+320 CALL ldxgpc() 105F16F28 ? 105A3F5A0 ?
000000002 ?
FFFFFFFF7AA292E0 ?
FFFFFFFF7AA2A310 ?
000000248 ?
evaopn2()+360 PTR_CALL 0000000000000000 4703D80B8 ? 1039271C0 ?
FFFFFFFF7AA2A068 ?
FFFFFFFF7AA2A078 ?
105F16F28 ? 000000D98 ?
…
I searched the method names appeared on error stack in meatlink, found out that the functions starts with ldx is likely related to NLS. In the problematic sql, the only thing seems to be remotely related to NLS is the trunk(sysdate). Evadrn called ldxgpc and the error stack shows the argument. The first one, 105F16F28 , is pointer, in that location, it is 0x100000000000008B. The second one ,105A3F5A0, is also a pointer, and it turns out to be “DD…” in that memory location. The third one is apparently a number, 2. Could it be the length of the second parameter? The trunc function can take 2 arguments where the the second argument is the format. And trunc(
No comments:
Post a Comment