I am debugging a method inside a database package in 11g version 11.1.0.7.0. When the debugger stays inside the initial package, I can break (stop) the debugger almost every time, but when the debugger calls into a method in another package, I can not break the debugger immediately. Instead, it behaves like step out (Ctrl-T), i.e. each time I press the break button, the debugger goes to a line in a method at a call level 'above' the current line.

As I recall, this was also a problem in one of the early 8a versions, but that time with a 10g database.

Could this behaviour be corrected with a high priority, as this stops me from debugging effectively on a 11g database.

BTW: if you try to close the test window, and select Terminate in the following dialog, you can watch PLD go to all the 'breakpoints' before closing the window.

I checked this on 11.1.0.6 and it works fine. I will try this on 11.1.0.7 as well.

I am getting an Oracle error now.

I make a test script where I test a method in a package (P1) containing approx. 2100 lines of code. This method in turn calls a method in another package (P2) containing approx. 6400 lines of code.

I make a breakpoint in the method in P2. When I run the test script to the breakpoint and break the debugger, I get the error: File debug.sql will be sent to support.

A simple test script:Enter debug mode. The cursor is at the first line. Pressing the Break button, the cursor moves to the second line. Pressing Break again breaks the execution.

Performing the same steps again (in same test window), this time results in a delay of some seconds (depending on the connection to the database) and showing of message "ORA-01013: user requested cancel of current operation"

Performing the same operation again results in the first described behaviour (without message) and the behaviour shifts back and forth.

Any news on this? It has become quite an annoying business to debug code on an 11g base.

This is still under investigation.

I'm using 8.0.1.1502 and am getting slightly different issue around debugging. As soon as an error is raised developer hangs. Break can sometimes sort it out but sometimes just need to kill the windows process. This makes debugging almost impossible.

declare
PROCESSING_E exception;
pragma exception_init ( PROCESSING_E, -20099 );
begin
raise PROCESSING_E;
end;

Running the above is fine but if you debug through by stepping over every line after stepping over the raise statement developer hangs for a few seconds then seems to return - run, step into, etc. buttons become enabled but no error is raised. The only way to progress is hit break a number of times (and the number does seem to vary). At some point a ORA-01013 error is returned - after hitting OK the error is raised five or six times. In a more complex program often no ORA error is returned and therefore its impossible to get control back.

Thanks Jules for a very nice example.

I have given it to our DBA, who has run it on Toad, but it did not hang up. But on the other hand, the debugger in Toad does not singlestep the code like PL/SQL Developer does. It seems more like like it sets a breakpoint and run to that breakpoint. But anyway, the ORA-20099 always comes up on Toad.

Can anyone try to reproduce this with Oracle SQL Developer?

Marco, how are the investigations comming?

I have tried today with Oracle SQL Developer. This debugger works (it does not hang up).

I have made the block from Jules into a procedure TESTER and debugged it in Oracle SQL Developer.

The output from the debugger is as follows:
Maybe someone can figure out, what Oracle does differently from PL/SQL Developer.

Marco, you must really try to find a solution to this. My company are installing more and more 11g databases for our customers and if the developers/support teams are not able to debug properly without loosing data and potentially locking the customers tables because of a hanging debug session, we may have to be forced to look at other development tools for debugging porposes