Debuger hangs

psilva

Member
I have Oracle 9i R2
When trying to debug it stops (?) at de debug point but hangs. It is not possible to continue (F8 or F9) and the cursor keeps an hourglass
 
Is this hangup occurring on the client or on the server? In other words, is there a 100% CPU usage on the PC for the plsqldev process?

------------------
Marco Kalter
Allround Automations
 
Could there be a lock, or a long running query that performs internal sorts?

------------------
Marco Kalter
Allround Automations
 
We had recently purchased PL/SQL Developer and after one or two of my colleagues run the PL/SQL Debugger, it causes the Oracle Server to crash. On a closer look at it, it seems like the Debugger is causing an infinite loop to be executed, which causes the Server to be starved of any resources. Even such a session could not be killed. So, the Admin tries to login via sys and tries to 'shutdown immediate' and even that doesn't work. Finally the Admin, is forced to do a 'shutdown abort' and then restarts the Oracle Server 9.2.

This is becoming a problem, primarily because, not only the Server is crashing and not responding, but even it doesn't allow certain packages to compile, because of the locks being held by the Debugger loop ad infinitum while it goes into a silent oblivion
 
The problem as to do with Oracle 9i, because on Oracle 8i the same debug works well. It only hapens on some packages, not all.
In others words: in the debug wiwdow it opens the package, shows the line with the debug point, but it doesn't stop there. it finish the task and commits the transaction
because after killing the pl-sql developper application I have all the information as if I run without the debug point.

Thanks

PSilva
 
I have the same problem.

I got the same versions of Oracle and PL/SQL Developer. Can't step through the code while debugging. PL/SQL Dev hangs and I am the only user on the database, no one else has any locks or are running any query on the server.
 
We have PL/SQL Developer Version 5.0.2.500 and accessing Oracle 8.1.7 standard edition. Found debug uitility very slow and sometimes session hangs and got to kill session which also takes sometime. Do I need to check any preference options.
Please advice.
 
For 5.0.2 you should definitely ugrade to 5.0.3. This may help.

I will look into the 9.2 issue.

------------------
Marco Kalter
Allround Automations
 
Upgraded to PL/SQL Developer to 5.1.1, still having the same problem in Debug mode.
Sequence of steps:-
1.Right click on the procedure and select Test.
2.Clicked start debugger.
3. Windows microhelp displays Executing..

Wait for a while(2 minutes, which is not acceptable for developers) had to kill the session.
Please advice.
 
I'm using PLSQL Developer 5.1.1 and Oracle 9i release 2 both under Windows 2000 Professional on the same PC and had the debugger hang only once (had to bounce the box) - but I have used the debugger successfully on many other occasions. I did encounter the problem when the debugger shows the wrong line being executed in IF ... ELSIF ... ELSE ... END IF; statements, but I believe this is a known Oracle bug.

I've also had no problem debugging Oracle 8.1.7 code on a remote database.

I know this does not help solve the problem but I think it might be an Oracle issue more than a PLSQL Developer issue.

Thanks,

[This message has been edited by CTucker (edited 09 April 2003).]
 
Originally posted by mkalter:
For 5.0.2 you should definitely ugrade to 5.0.3. This may help.

I will look into the 9.2 issue.


Hi,

We are facing the same problem.

Env: Oracle 9i R2 on Linux, PL/SQL Developer 5.0.3.527. on Windows NT 4

It happens within one package after open/fetch a cursor with lots of columns. After this it hangs on different lines within the function. The packages used within the function are all locked so no recompilation is possible. We have to restart the db with 'shutdown abort'(startup force). Looks like a memory issue(?)

Please advise as soon as possible. We need a working environment / toolset for our ongoing development work!

cheers,
Joerg
 
Whoever mentioned the memory problem is correct. In Win 2000 if I TYPE a SELECT statement (SELECT * FROM PS_ ) the program seems to hang after typing the PS_, ie I want to type the table name but PLSQLDev.exe goes off and does something. When I look at the task manager I can see that it's memory usage just keeps incrementing (up to 200Mb+, I only have 256Mb) until finally I get a message saying it's out of memory. Seems like a memory leak to me or are there MAJOR memory requirements?
 
PL/SQL Developer 5.1.1,Debug hangs with Oracle 8.1.7 Release 3. Had to bounce the server.
Please advice.
 
Originally posted by markshearing:
...the program seems to hang after typing the PS_, ie I want to type the table name but PLSQLDev.exe goes off and does something.
This seems like a Code Assistant problem. What happens if you disable the "Describe Context" option (Tools > Preferences > Code Assistant tab page)? This should fix it.

------------------
Marco Kalter
Allround Automations

[This message has been edited by mkalter (edited 11 April 2003).]
 
Hi

Greate product and used the demo. version
to debug some database procs. successfuly.

Bought the product today, and downloaded the
latest, and used the debugger: when instructed
it to step into the proc, it steps into
the spec of the procedure!!

Tried numerous times.

Any help would be appreciated:

Using 9.2 client on 8.1.7 server, on
win2K, with version 5.1.1.672.

regs
beez
 
Are there any default assigned to variables, constant settings etc done in the spec of the procedure? If so, then it's the way Oracle steps into the procedure. First it sets the defaults for the variables and then goes into the 'real' code.
Makes sense to me.

------------------
Check out: http://www.oracledeveloper.nl
 
Hey Patch

Thanks! you are 100% correct.

However, Developer, does not, go into the
body of the procedure after setting the constants, which may be a bug...

In any case, it would be great to know how
to get the debugger to do its thing and
go into the body of the proc. which I need
to test.

regs
beez
 
You will need to "step into" the assigment of the constant(s). Otherwise the debugger will also step over the called procedure/function.

------------------
Marco Kalter
Allround Automations
 
Originally posted by sam:

Sequence of steps:-
1.Right click on the procedure and select Test.
2.Clicked start debugger.
3. Windows microhelp displays Executing..

Wait for a while(2 minutes, which is not acceptable for developers) had to kill the session.
Please advice.
Hi all, I use the last version on W2000 and XP client.
I have the same problem. Is impossible to test every stored object.
Please help me.
Thanks in advance,
Massimo.
 
I hear from customers that inscreasing the shared pool size can help in case of debugger stability issues. Can you try that?
 
This might be a simple question, but are any one of you who have debugger issues running RAC?

We had issues with debugger with RAC and using a specific type of tnsnames ...
Raj
 
We have also run into a similar problem with 9i (did not have issues with 8i). Seems to be when we are assigning default values to variables outside of the BEGIN/END statements that causes the debugger to hang. We are not seeing usage issues on the server though.

Any thoughts on what is required to fix this?
 
Ive had this problem alot.
Make sure you connect with a dedicated connection.
It has reduced hangups for me.

I also notised that after you break a debug session it will hang the time you start the debug after.

The hang up usually timeout after a long while, but its to long.

Best regards
/Olof
 
Originally posted by Marco Kalter:
I hear from customers that inscreasing the shared pool size can help in case of debugger stability issues. Can you try that?
That didn't fix it, we increased it from 25 to 45 MB, is this still not enough?
On our side the problem exists only with Oracle 9.2 when debugging quite large packages.
The Debugging Session always waits for 'pipe get' and the Main and Secondary Session for 'SQL*Net message from client'. Only the Debuggin Session is active.
 
I'm not sure if 45MB is enough. It depends on the number of users, pool fragmentation, and other factors. If it also happens of a freshly started instance with a pool size of 45MB, then I would guess that it is not memory related.
 
You may want to check Metalink because I have seen a few bugs regarding large PL/SQL packages and causing a loop while using dbms_debug package.
 
We're suddenly getting the same debugger hanging up issues. Oracle 9i. It gets to the breakpoint, and as soon as I mouse over a variable to see the value, it goes THARN. Have to kill it.
What information would be helpful in diagnosing htis?
The package size isn't huge, the packages are in the 1000 - 2000 line rage. The breakpoints can be at the first package or deeply nested, doesn't seem to matter.
Thanks, Ed Delaney
 
Hi,

I am having the same problem since this morning.
Package has around 1400 lines in the body and 230 lines in the spec.
Debugging went well for the last three weeks but now stops at the breakpoint and doesn't continue.
This doesn't happen if the breakpoint is within the package spec or if I am debugging the package on our test system.
Doing so on the produvtive system it hangs up and can only be killed via task manager.
If it hangs up the local CPU Usage of the plsqldev.exe

I am using PL/SQL Developer 5.1.6.747 and Oracle 9.2.0.2.0 on the productive and 9.2.0.4.0 on the test system.

ciao
Martin

PS: If I make a new package and copy parts from the other one to the new one debuging works fine, even on the productive system
 
If the exact same package can be debugged in one database and not in the other, then I expect that there is some relevant difference between these 2 databases. Perhaps it is the shared pool size or fragmentation of the shared pool. Restarting the instance would fix this, but this may be difficult for a production database. Can you try this?
 
The first visible difference is that the version number of the test system (the one where I ca ndebug is 9.2.0.4.0) and that of the productive system is just 9.2.0.2.0.

I don't know if there are some other differences but there shouldn't be some, because it would make it complicated to run useful tests for the productive use if I use different bases.

But I will ask my DB Admin if there are any and also if it would be possible to change something about this shared pool (whatever that is :-))

bye
Martin
 
So, I spoke to my admin and the shared pool size was different. 64 MB on the test and 48 MB on the productive system.

Instead of changing the produvtive system we changed the test system to see if the same error would occur. But it is still possible to debug there.

BUT, the most mysterious thing is, that suddenly I can debug the package again even on the produvtive system. I tried it this morning and it hang up. Through out the day I changed some methods, added some constants and methods.
When I was about to write this posting I just thought of trying out if it is possible to debug on the test but not on the productive system.

And wushhh it was possible again.

Might be it is something about the weather, the oil prices or we had extraordinary sun activity yesterday. :-)

No matter what it was, I hope it stays the way it is right now.

bye
Martin
 
Hi it's me again.

Another day, the same problem. This morning no debugging on the productive system was possible and I made no changes (!) to the package since yesterday.

Just to be sure that it is a Oracle problem which I was convinced of, I installed another program which is able to debug PL/SQL Packages.

And to my suprise this program was able to debug the package. To be on the secure side I tried the same with PL/SQL Developer just a minute after I finished with the other program and it failed.

In my opinion this points out that the error must be on the side of PL/SQL Developer and not on the Oracle side.

bye
Martin

------------------

We updated the database to version 9.2.0.4.0 last weekend and it's possible to debug again.
Seems that there is a bugfix for that problem.
I couldn't find one in MetaLink which fits to the problem but maybe it's just caused by some side effects.
 
Back
Top