4 Replies Latest reply on Mar 30, 2018 7:13 PM by rp0428

    What is the ETA on a patch fix for ORA-03137 [12333] ?

    charlesdschultz

      Good day,

       

      We seem to have a plague of issues arising from a scenario when a user sees this on the screen:

      sql_dev_reconnect_error_internal_error_core_dump.png

      The details show:

       

      java.lang.NegativeArraySizeException
      at oracle.net.ano.CryptoNIONSDataChannel.readDataFromSocketChannel(Unknown Source)
      at oracle.jdbc.driver.T4CMAREngineNIO.prepareForReading(T4CMAREngineNIO.java:98)
      at oracle.jdbc.driver.T4CMAREngineNIO.unmarshalUB1(T4CMAREngineNIO.java:534)
      at oracle.jdbc.driver.T4CTTIfun.receive(T4CTTIfun.java:485)
      at oracle.jdbc.driver.T4CTTIfun.doRPC(T4CTTIfun.java:252)
      at oracle.jdbc.driver.T4C8Oall.doOALL(T4C8Oall.java:612)
      at oracle.jdbc.driver.T4CCallableStatement.doOall8(T4CCallableStatement.java:223)
      at oracle.jdbc.driver.T4CCallableStatement.doOall8(T4CCallableStatement.java:56)
      at oracle.jdbc.driver.T4CCallableStatement.executeForRows(T4CCallableStatement.java:907)
      at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1119)
      at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3780)
      at oracle.jdbc.driver.T4CCallableStatement.executeInternal(T4CCallableStatement.java:1300)
      at oracle.jdbc.driver.OraclePreparedStatement.execute(OraclePreparedStatement.java:3887)
      at oracle.jdbc.driver.OracleCallableStatement.execute(OracleCallableStatement.java:4230)
      at oracle.jdbc.driver.OraclePreparedStatementWrapper.execute(OraclePreparedStatementWrapper.java:1079)
      at oracle.jdbc.proxy.oracle$1dbtools$1raptor$1proxy$1driver$1oracle$1RaptorProxyOJDBCStatement$2oracle$1jdbc$1internal$1OracleCallableStatement$$$Proxy.execute(Unknown Source)
      at oracle.dbtools.db.OracleUtil.checkAccessImpl(OracleUtil.java:389)
      at oracle.dbtools.db.DBUtil.checkAccess(DBUtil.java:1814)
      at oracle.dbtools.db.AccessCache.checkAccess(AccessCache.java:68)
      at oracle.dbtools.db.AccessCache.hasAccess(AccessCache.java:59)
      at oracle.dbtools.db.AccessCache.hasAccess(AccessCache.java:28)
      at oracle.dbtools.raptor.query.QueryUtils.checkNonOracleAccess(QueryUtils.java:603)
      at oracle.dbtools.raptor.query.QueryUtils.getQuery(QueryUtils.java:409)
      at oracle.dbtools.raptor.query.ObjectQueries.getQuery(ObjectQueries.java:44)
      at oracle.dbtools.raptor.navigator.db.xml.XmlNodeInstance.listChildren(XmlNodeInstance.java:48)
      at oracle.dbtools.raptor.navigator.db.impl.DatabaseObjectTreeNode$LoadTask.doWorkImpl(DatabaseObjectTreeNode.java:163)
      at oracle.dbtools.raptor.navigator.model.NavigatorQueryTask.doWork(NavigatorQueryTask.java:57)
      at oracle.dbtools.raptor.navigator.model.NavigatorQueryTask.doWork(NavigatorQueryTask.java:17)
      at oracle.dbtools.raptor.backgroundTask.RaptorTask.call(RaptorTask.java:193)
      at java.util.concurrent.FutureTask.run(FutureTask.java:266)
      at oracle.dbtools.raptor.backgroundTask.RaptorTaskManager$RaptorFutureTask.run(RaptorTaskManager.java:629)
      at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
      at java.util.concurrent.FutureTask.run(FutureTask.java:266)
      at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
      at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
      at java.lang.Thread.run(Thread.java:745)

       

       

      However, what is worse is that this generates a 600MB core dump on the back end database server FOR EVERY SINGLE ERROR. That consumes a lot of disk space. How do we fix this?

       

      Example of error from the database point of view (from alert.log):

      Fri Mar 30 11:05:43 2018

      Errors in file /u01/app/oracle/diag/rdbms/bandev/BANDEV/trace/BANDEV_ora_28701.trc  (incident=273405):

      ORA-03137: TTC protocol internal error : [12333] [138] [27] [223] [] [] [] []

      Incident details in: /u01/app/oracle/diag/rdbms/bandev/BANDEV/incident/incdir_273405/BANDEV_ora_28701_i273405.trc

       

      From /u01/app/oracle/diag/rdbms/bandev/BANDEV/trace/BANDEV_ora_28701.trc:

      ...

      ttcdrvdmplocation: msg--118 ln-1022 reporting 12333

      hstflg:  0x40202d81

      hstcflg: 0x00000000

      hstpro:  6

      hstccs:  (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=xx.xx.xx.xx)(PORT=1521))(CONNECT_DATA=(CID=(PROGRAM=SQL Developer)(HOST=__jdbc__)(USER=xxxxx))(SERVICE_NAME=xxxx)))

      --- dump of hsttti ---

      ...

       

      From /u01/app/oracle/diag/rdbms/bandev/BANDEV/incident/incdir_273405/BANDEV_ora_28701_i273405.trc:

      Dump continued from file: /u01/app/oracle/diag/rdbms/bandev/BANDEV/trace/BANDEV_ora_28701.trc

      ORA-03137: TTC protocol internal error : [12333] [138] [27] [223] [] [] [] []

       

       

      ========= Dump for incident 273405 (ORA 3137 [12333]) ========

       

       

      *** 2018-03-30 11:05:43.570

      dbkedDefDump(): Starting incident default dumps (flags=0x2, level=3, mask=0x0)

      ----- Current SQL Statement for this session (sql_id=8gnjy50gxbwnc) -----

      declare

         l_schema      varchar2(128);

         l_part1       varchar2(128);

         l_part2       varchar2(128);

         l_dblink      varchar2(128);

         l_part1_type  number;

         l_objid       number;

      begin

      DBMS_UTILITY.NAME_RESOLVE (

         name          => :obj_name,

         context       => 2,  -- interested in dba_ views only; 0 doesn't work in 10g -- bug 19528375

         schema        => l_schema,

         part1         => l_part1,

         part2         => l_part2,

         dblink        => l_dblink,

         part1_type    => l_part1_type,

         object_number => l_objid );

      end;