Issue 4694 in pharo: Debugger: stepping over an error can not open a new debugger

Status: New
Owner: ----

New issue 4694 by [hidden email]: Debugger: stepping over an error  
can not open a new debugger
http://code.google.com/p/pharo/issues/detail?id=4694

Short description: Debuggers out of debuggers sometimes don't work.

Long description (this is what happened):

1. An error opened a debugger
2. I restarted (a few lines down)
3. I stepped over, also over the code that produced the error
4. No debugger was opened until I hit cmd-. (=problem 1)
5. Then, the user interrupt opened a debugger and another debugger was  
opened in front (with the error I triggered)
6. In this debugger, I restarted again
7. The context was not found, so I could not continue debugging (=problem 2)
8. I gave up and closed all debuggers
9. the image crashed (=problem 3)



Pharo image: Pharo
Pharo core version: Pharo1.2.2
Virtual machine used: Mac Squeak 4.2.2beta1U
Class browser used: OBSystemBrowserAdaptor


Attachments:
        stackTraceDebuggerAndCrash.log  289 KB


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: Accepted
        Labels: Milestone-1.4

Comment #1 on issue 4694 by [hidden email]: Debugger: stepping over  
an error can not open a new debugger
http://code.google.com/p/pharo/issues/detail?id=4694

(No comment was entered for this change.)


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #2 on issue 4694 by [hidden email]: Debugger: stepping over  
an error can not open a new debugger
http://code.google.com/p/pharo/issues/detail?id=4694

do you have an example that we can reproduce?


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Labels: -Milestone-1.4

Comment #3 on issue 4694 by [hidden email]: Debugger: stepping over  
an error can not open a new debugger
http://code.google.com/p/pharo/issues/detail?id=4694

(No comment was entered for this change.)


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #4 on issue 4694 by [hidden email]: Debugger: stepping over  
an error can not open a new debugger
http://code.google.com/p/pharo/issues/detail?id=4694

I tried to create a reproducible case, but I could not from the provided  
description.

Here is what I have:
| a b c |
a := 1.
b := 0.
c := a / b.
c + 1

But, stepping through the execution does not seem to create a problem.


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #5 on issue 4694 by [hidden email]: Debugger: stepping  
over an error can not open a new debugger
http://code.google.com/p/pharo/issues/detail?id=4694

I finally managed to create a generally reproducible case! The problem is  
in the Seaside error handling! Especially in SeasidePlatformSupport  
openDebuggerOn:.

(pharo 1.3 #13315)

1. Load Seaside
2. Run a demo application, e.g. WACounter
3. Change its errorHandler from WAWalkbackErrorHandler to  
WADebugErrorHandler
4. Put a 1/0 in the WACounter render code
5. Trigger the error
6. A debugger is opened
7. Do a restart
8. Step over the error
9. Nothing happens until you hit cmd+. (= problem 1)
10. hit cmd+.
11. You get 2 more debuggers
12. Try to fix the 1/0 and proceed! (You will not succeed, or tell me the  
secret) (= problem 2)




My workaround is to avoid SeasidePlatformSupport openDebuggerOn: and  
instead just write anError pass. It anyway happens only in development mode  
for me because in production mode, the error is handled different.

The reason why it happens in pharo but not in Squeak must be somehow  
connected to the deferredUIMessage and the process handling.

SeasidePlatformSupport>openDebuggerOn: anError
        | process |
        process := Processor activeProcess.
        WorldState addDeferredUIMessage:
                [process
                        debug: anError signalerContext
                        title: anError description
                        full: true].
        process suspend


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #7 on issue 4694 by [hidden email]: Debugger: stepping over  
an error can not open a new debugger
http://code.google.com/p/pharo/issues/detail?id=4694

So what's the right way to open a debugger?


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Comment #8 on issue 4694 by [hidden email]: Debugger: stepping  
over an error can not open a new debugger
http://code.google.com/p/pharo/issues/detail?id=4694

I don't know what's the right way, but I do it this way:

anError pass

I think opening the debugger is not the responsibility of Seaside, only the  
decision if an error should open a debugger or be handled differently. At  
least if opening a debugger is as problematic as it seems in the above use  
case :-) But well, maybe it should be possible to really open a debugger by  
yourself, I don't know...


_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker

Updates:
        Status: Closed

Comment #9 on issue 4694 by [hidden email]: Debugger: stepping over  
an error can not open a new debugger
http://code.google.com/p/pharo/issues/detail?id=4694

With Pharo 2.0 now beta, time has come to review bug reports that have not  
seen any activity in 2012.
To keep the amount of issues managable, we close reports that have not  
drawn any attention for over one
year.

The reporter (and thus owner) of the issue should:

  -> check the issue in 2.0. Is it still relevant?
  -> If yes, just add a note to the report and we will be opened again.


As your issue has not seen any attention for over a year, please consider  
to give more information.
A good idea can be to send a mail to the mailinglist to get other people to  
help fixing the bug or
implementing an improvement.



_______________________________________________
Pharo-bugtracker mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-bugtracker