Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Need Help Debugging: Oracle 8.1.5 PMON Crash, ORA-07445, and dbms_session.set_context
ABSTRACT:
PMON gets SIGSEGV and takes down the instance. This only happens when
sessions have been disconnected from their clients, or are otherwise
out of communication.
I have a test-case that will always crash the server. I need help reproducing the crash on other systems, so I can see if this is specific to my installation, a generic bug in Oracle8i, or common to Oracle8i on Solaris.
QUESTIONS:
Can someone else verify this problem on a development instance?
Is this a known bug?
Any idea as to causes?
CONFIG:
Oracle 8.1.5.0.0 Workgroup Server (Not EE)
No Extra Cartriges Running (ConText, etc.) Not running MTS About 200M total SGA on 1GB machine shared_pool_size = 33554432 db_block_buffers=16384 db_block_size=8192 Very light txn volume for this config.Solaris 2.6 (SunOS xxxxxx 5.6 Generic_105181-15 sun4u sparc SUNW,Ultra-4)
PROBLEM:
If a session has called the following PL/SQL code, and the client
ever loses communication with the server or is forceably killed,
then ORACLE will crash some time later (30m to 3h).
If rather than waiting, you shut down with SHUTDOWN IMMEDIATE, the crash will occur immediately. This is 100% reproducable on my installation.
The trace files of
ALTER SYSTEM SET EVENTS '10046 trace name context forever, level 10'
from the test case, and the pmon crash log are at:
http://www.impole.com/people/jnield/oralogs/
TEST:
Before we can test, we need to create a simple package, and two test
users:
<code>
connect jnield_dba;
create user bugtestA identified by foo
default tablespace user_ts
temporary tablespace tempa_ts;
grant create session to bugtestA;
grant create any context to bugtestA;
grant create procedure to bugtestA;
create user bugtestB identified by foo
default tablespace user_ts
temporary tablespace tempa_ts;
grant create session to bugtestB;
</code>
Now connect as bugtestA/foo:
<code>
create or replace context bugtest_ctx using pkg_ctxtest;
create or replace package pkg_ctxtest is
procedure init;
procedure testproc;
end pkg_ctxtest;
create or replace package body pkg_ctxtest is
procedure testproc is
begin
null;
end;
procedure init is
begin
--| This seems to be the cause of the problems:
dbms_session.set_context('bugtest_ctx', 'test', '111');
end;
begin
init;
end pkg_ctxtest;
grant execute on pkg_ctxtest to bugtestB;
</code>
Now we are ready to cause the crash. To reproduce the crash connect as bugtestB:
<code>
sqlplus bugtestB_at_imp1
exec bugtestA.pkg_ctxtest.testproc;
</code>
Note that we use user_at_instance to force us to go through the listener. This crash will also happen when connecting over the network from another machine.
Now we stop bugtestB's sqlplus client to simulate it being disconnected or otherwise becoming uncommunicable. This works from other clients than sqlplus (Visual Basic/OO4O as an example). The key to this test is that the client is never able to tell Oracle that it wants to disconnect.
kill -STOP <pid of bugtestB's sqlplus process>
We are now in a situation where bugtestB's session will be marked as SNIPED in a little while. The server will crash in a few hours unless the client becomes communicable before the session is marked.
For repeatability, we are going to force the issue by shutting down the instance with SHUTDOWN IMMEDIATE. There is no need to wait for bugtestB's session to change status, it will still crash.
<code>
sqlplus /nolog
connect / as sysdba
shutdown immediate
</code>
Results in:
<output>
ORA-24323: value not allowed
ORA-01041: internal error. hostdef extension doesn't exist
</output>
(The sysdba session was kicked)
In the alert_imp1.log:
<output>
Sun Nov 7 21:58:24 1999
Errors in file /u01/app/oracle/admin/imp1/bdump/imp1_pmon_12783.trc:
ORA-07445: exception encountered: core dump [00000000] [SIGSEGV]
[Address not mapped to object] [0] [] []
Sun Nov 7 21:58:41 1999
CKPT: terminating instance due to error 472
Instance terminated by CKPT, pid = 12789
</output>
Note that the instance is terminated by whatever process notices PMON's death first, not necessicarily CKPT.
This crash happens every time, given the above instructions.
--
John Nield
jn-exposed-199911_at_impole.com
Received on Tue Nov 09 1999 - 18:41:51 CST