Hello,

My developers are reporting, that

The pbsde package is indeed used internally by the Oracle Debugger. I have seen reports where this problem is fixed by increasing the shared pool size for the database instance. Can you try this?

I don't belive it will help. I have 160Mb allocated to shared_pool in this particular instance. Plroblem reprodusable constantly, even immediately after instance restart.

I belive it is related to configuration. Are there any preconfiguration steps for PL/SQL Developer, before starting using DEBUG mode?

There is no real preconfiguration required, but as a result of previous dbms upgrades, the dbms_debug packages can cause problems. If this database instance has previously bee upgraded, you can logon to the server computer, go to $ORACLE_HOME/rdbms/admin, start SQL*Plus under the SYS account, and run pbload.sql. This will reload the dbms_debug packages. Check if this has a positive influence on the problem.

We're experiencing the problem in PLSD 6.0.2 using Oracle release 9.2.04. We started seeing the problem after installing Oracle Security Patch #68, but we haven't conclusively pegged that as the cause.

Reloading the package did not help, we resized the SGA and are waiting to see. The problem here is intermittent with various developers reporting the problem at different times.

Since the problem appears to be with the pipes implementation, I wrote a dummy application using DBMS_PIPES. Looping on a pipe read (dbms_pipe.receive_message) does make the application hang, but we don't get the 7445 error that we see when debugging is the source of the problem.

Any observations and comments y'all have are appreciated.

What version RDBMS?
Are you have system event trigger [after] servererror on database in your DB?

We are using Oracle 9.2.04.

Thanks for the suggestion, but we do not have after servererror triggers on the DB.

I've had reports that the problem exists in other applications also, so my suspicions that this is an Oracle problem and not a PLSD problem seem to be confirmed.

No progress on our TAR with Oracle yet. Still working on this. :rolleyes:

Hi,
I have a system event trigger (servererror) on database (9.2.0.4.0) and i'm having the same problem. It occurs when i click in "Break" (or Shift+Esc) while i'm in a debuging session.

Are there any workaround for this issue??

I find that I cannot break in a debug session until the debugger has stopped at a breakpoint. If I try to break a non-stopped process, one of the sessions stays active and has to be KILLed. Often the package I'm debugging stays locked and we have to bounce the database (easiest solution) to right things.

Another symptom I sometimes see if I break a process is that the debugger loses all of my breakpoints and the process runs to completion despite stepping or breakpoints.

My suggestion to you is to try not to break out of a debug process from the client until a breakpoint is reached. Having your DBA kill the session at the DB level also works.

FYI, when using the debugger you have two processes running, the program you're testing and the process that is stepping through it.

[quote]Originally posted by fabiorcg:
Hi,
I have a system event trigger (servererror) on database (9.2.0.4.0) and i'm having the same problem. It occurs when i click in "Break" (or Shift+Esc) while i'm in a debuging session.

Are there any workaround for this issue?? [/quote]It maybe Oracle bug.
It's a database event trigger "after servererror" on database or schema.
If there's a trigger on schema (even empty) it's
impossible to debug code in this schema (the session hangs) but
in other schemas there's no problems.
A trigger on database schema (even empty too) causes a session hang up
while debugging any code in this database.
create or replace trigger tr_error
after servererror on database|schema
begin
null;
end;
For instance, attempts to debug (step by step) this
function always fail (the debugger session hangs):
create or replace procedure debug_test_ver2
is
l_s varchar2(1);
begin
l_s:='xxx';
end;
It seems that the reason is that the line "l_s:='xxx';" raises an exception
which is catched by the database event trigger "after servererror"
and the debugger hangs. After killing the hung up sessions the server generates
two trace files (PBSDE.DEBUG_LOOP (WAIT = pipe get)...). If the trigger ("after servererror") is
dropped or disabled then everything works fine.