exceptions while debugging - frozen UI

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

exceptions while debugging - frozen UI

Holger Kleinsorgen-3
Hello,

the following freezes the Squeak UI:

- implement a callback as "self halt zork"
- trigger the callback in the webbrowser (e.g. click on an anchor with
this callback)
- the debugger pops up
- click on the callback method, step over halt, step over zork
- the web browser will now show the error in the usual way
- press debug
- UI is frozen, image is still alive


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: exceptions while debugging - frozen UI

Lukas Renggli
>  - click on the callback method, step over halt, step over zork

I cannot reproduce that. I get an internal error displayed in the web browser.

>  - UI is frozen, image is still alive

The problem is that you are trying to request another page in the same
session, while you have the stepping debugger open. Every session has
a mutex that prevents the handling of multiple requests though. Since
the debugger runs in the GUI thread this locks up Squeak.

If I press Ctrl+. and close the old debugger, I get a new one on the
message not understood zork. So everything seems normal here.

Generally you should avoid stepping over code that causes a response
to be sent out to the browser, like the error with the #zork, or when
doing a #call: or #answer:. In the current implementation this cannot
possibly work within a single debugger, as there are many different
processes involved (every request gets a new process).

Lukas

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: exceptions while debugging - frozen UI

Lukas Renggli
> >  - click on the callback method, step over halt, step over zork
>
> I cannot reproduce that. I get an internal error displayed in the web browser.

Sorry, that's for Seaside 2.9.

>  >  - UI is frozen, image is still alive

And that's for Seaside 2.8 (what you are probably using):

> The problem is that you are trying to request another page in the same
>  session, while you have the stepping debugger open. Every session has
>  a mutex that prevents the handling of multiple requests though. Since
>  the debugger runs in the GUI thread this locks up Squeak.
>
>  If I press Ctrl+. and close the old debugger, I get a new one on the
>  message not understood zork. So everything seems normal here.
>
>  Generally you should avoid stepping over code that causes a response
>  to be sent out to the browser, like the error with the #zork, or when
>  doing a #call: or #answer:. In the current implementation this cannot
>  possibly work within a single debugger, as there are many different
>  processes involved (every request gets a new process).

--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: exceptions while debugging - frozen UI

Colin Putney
In reply to this post by Holger Kleinsorgen-3

On 10-Apr-08, at 7:06 AM, Holger Kleinsorgen wrote:

> - UI is frozen, image is still alive

Hi Holger,

I've run into this myself. I haven't been able to pin down the exact  
cause, but I believe it's something like this: by opening a debugger,  
you are effectively transferring execution of the callback from a  
Seaside process to the UI process. When you step over the method that  
produces an HTTP response, Seaside uses an escape continuation to  
replace the stack of the UI process with the stack of the process that  
was serving the HTTP request. Once the response has been sent to the  
browser, that process exits, leaving you without a UI process.

It's probably not exactly like that, and probably the exact steps are  
different in the different versions of Seaside, but the effect is  
always that the UI process is destroyed when the HTTP response is sent  
out. Fortunately, there's an easy work around. Just press cmd-. to  
create a new UI process and you're fine.

Colin


_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: exceptions while debugging - frozen UI

Holger Kleinsorgen-3
>> - UI is frozen, image is still alive
>
> Hi Holger,
>
> I've run into this myself. I haven't been able to pin down the exact
> cause, but I believe it's something like this: by opening a debugger,
> you are effectively transferring execution of the callback from a
> Seaside process to the UI process. When you step over the method that
> produces an HTTP response, Seaside uses an escape continuation to
> replace the stack of the UI process with the stack of the process that
> was serving the HTTP request. Once the response has been sent to the
> browser, that process exits, leaving you without a UI process.
>
> It's probably not exactly like that, and probably the exact steps are
> different in the different versions of Seaside, but the effect is always
> that the UI process is destroyed when the HTTP response is sent out.
> Fortunately, there's an easy work around. Just press cmd-. to create a
> new UI process and you're fine.


thank you both for the explanation and the solution.

 > And that's for Seaside 2.8 (what you are probably using):

exactly
_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside