'self halt' safety net

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

'self halt' safety net

Ben Coman
As probably many newbies do from time to time, I am learning the system
splattering 'self halt' around, and once again slipped one into the
wrong place where I should have used 'haltOnce' and had a massive number
of pre-debugger windows come up.  I managed to get it back this time
with the user interrupt - but not always - and anyhow clearing so many
debug windows is a pain.  So..... could 'self halt' be made to monitor
the rate that the halt windows appear, and when more than some value
from one of them (say five per second) it starts getting ignored and
shows a dialog asking the user if they really meant this and enable
danger mode, or if they screwed up and want to revert the method
containing the suspect 'halt'.

Advanced features
+ button to close all debugger windows.
+ display the method showing the suspect 'self halt'

Another thought, it would be useful to be able to see a list of 'self
halts' throughout the system and the timestamp of when they were insert,
and perhaps distinguish whether they were inserted by the user or came
when the package was loaded - and so providing more functionality than
just using the Finder to 'search source'.

Another thought, are there any plans for a "breakpoint" facility, so
that I don't dirty a package by only inserting 'self halt' to aid
debugging.  The effect would be just the same as a 'self halt' and even
be compiled in to the bytecode as if it was but the source code remains
pristine.  This could be represented by a symbol that could be dragged
through a code window to anywhere immediately following a statement
separator.  Perhaps the statement separator itself gets special
significance as a point that could be activated as a debug point - and
displayed using a big red font when it is active.

anyhow, just musing....  
-ben

Reply | Threaded
Open this post in threaded view
|

Re: 'self halt' safety net

Igor Stasenko
On 4 August 2012 04:11, Ben Coman <[hidden email]> wrote:

> As probably many newbies do from time to time, I am learning the system
> splattering 'self halt' around, and once again slipped one into the wrong
> place where I should have used 'haltOnce' and had a massive number of
> pre-debugger windows come up.  I managed to get it back this time with the
> user interrupt - but not always - and anyhow clearing so many debug windows
> is a pain.  So..... could 'self halt' be made to monitor the rate that the
> halt windows appear, and when more than some value from one of them (say
> five per second) it starts getting ignored and shows a dialog asking the
> user if they really meant this and enable danger mode, or if they screwed up
> and want to revert the method containing the suspect 'halt'.
>
> Advanced features
> + button to close all debugger windows.

i think there already such.. ( Camillo did that today before my eyes,
with the shortcut only he knows ;)

> + display the method showing the suspect 'self halt'
>
> Another thought, it would be useful to be able to see a list of 'self halts'
> throughout the system and the timestamp of when they were insert, and
> perhaps distinguish whether they were inserted by the user or came when the
> package was loaded - and so providing more functionality than just using the
> Finder to 'search source'.
>
IMO, there should be no senders of #halt except from debugging purposes..
of course if package doesn't overrides it for own purposes.. (but i
doubt that even if one needs that,
it is good idea)

> Another thought, are there any plans for a "breakpoint" facility, so that I
> don't dirty a package by only inserting 'self halt' to aid debugging.  The
> effect would be just the same as a 'self halt' and even be compiled in to
> the bytecode as if it was but the source code remains pristine.  This could
> be represented by a symbol that could be dragged through a code window to
> anywhere immediately following a statement separator.  Perhaps the statement
> separator itself gets special significance as a point that could be
> activated as a debug point - and displayed using a big red font when it is
> active.
>

Opal... we need opal. so we can hack the method's bytecode without
need to recompile the method .
Also, there is other tools like method wrappers.. but they are not
come as part of pharo by default.


If we look from user's perspective (not machine perspective), apparently
it is pointless to throw so many messages at the user's face, because
he cannot deal with them
in meaningful manner at such rate.
So, i think there should be something like following:
- if exception requires a user interaction, we do show the popup, but
meanwhile remember
the exception which initiated it.
- if there's next exception incoming and also asks UI manager to show
it to user, we queue it,
letting user to deal with first one.. (or we delay the popup , say 1
each 5 seconds).
and finally, a queue should have some reasonable limit, after which we
stop queuing , because again, user certainly won't be willing to waste
his time dealing with 10000000 exceptions of same kind one by one. It
doesn't makes sense anyways.

In such case we can just ignore halt and let program continue (but
increment some counter to show user how many of them are there).
If exception is different (an Error) then on queue overflow, i think
it should terminate the process with exception (but of course, special
care must be taken if process is UI process).
Of course making it too smart is pointless, because it is impossible
to predict whether it is good idea
to terminate process or letting it continue to run in case of exception.
But for that we can have settings and options, to tune that at user's
discretion, as well as default
settings on a per-exception class base.

> anyhow, just musing....  -ben
>

i know by myself how annoying it can be (up to unresponsive image)
and i think most of us is facing such situation time to time (heh..
just yesterday we had it with Camillo while hacking ocompletion
stuff).
i learned to be careful and avoid such situations.. but sometimes it
is hard and better tooling support will be helpful, no doubt.

--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: 'self halt' safety net

Ben Coman
Igor Stasenko wrote:

> On 4 August 2012 04:11, Ben Coman <[hidden email]> wrote:
>  
>> As probably many newbies do from time to time, I am learning the system
>> splattering 'self halt' around, and once again slipped one into the wrong
>> place where I should have used 'haltOnce' and had a massive number of
>> pre-debugger windows come up.  I managed to get it back this time with the
>> user interrupt - but not always - and anyhow clearing so many debug windows
>> is a pain.  So..... could 'self halt' be made to monitor the rate that the
>> halt windows appear, and when more than some value from one of them (say
>> five per second) it starts getting ignored and shows a dialog asking the
>> user if they really meant this and enable danger mode, or if they screwed up
>> and want to revert the method containing the suspect 'halt'.
>>
>> Advanced features
>> + button to close all debugger windows.
>>    
>
> i think there already such.. ( Camillo did that today before my eyes,
> with the shortcut only he knows ;)
>
>  
>> + display the method showing the suspect 'self halt'
>>
>> Another thought, it would be useful to be able to see a list of 'self halts'
>> throughout the system and the timestamp of when they were insert, and
>> perhaps distinguish whether they were inserted by the user or came when the
>> package was loaded - and so providing more functionality than just using the
>> Finder to 'search source'.
>>
>>    
> IMO, there should be no senders of #halt except from debugging purposes..
> of course if package doesn't overrides it for own purposes.. (but i
> doubt that even if one needs that, it is good idea)
>
>  
As an extension to debugging, it is useful when trying to learn and
understand any particular framework for which there is little
documentation.  But sometimes I forget where I put them all.

>> Another thought, are there any plans for a "breakpoint" facility, so that I
>> don't dirty a package by only inserting 'self halt' to aid debugging.  The
>> effect would be just the same as a 'self halt' and even be compiled in to
>> the bytecode as if it was but the source code remains pristine.  This could
>> be represented by a symbol that could be dragged through a code window to
>> anywhere immediately following a statement separator.  Perhaps the statement
>> separator itself gets special significance as a point that could be
>> activated as a debug point - and displayed using a big red font when it is
>> active.
>>
>>    
>
> Opal... we need opal. so we can hack the method's bytecode without
> need to recompile the method .
> Also, there is other tools like method wrappers.. but they are not
> come as part of pharo by default.
>
>
> If we look from user's perspective (not machine perspective), apparently
> it is pointless to throw so many messages at the user's face, because
> he cannot deal with them
> in meaningful manner at such rate.
> So, i think there should be something like following:
> - if exception requires a user interaction, we do show the popup, but
> meanwhile remember the exception which initiated it.
> - if there's next exception incoming and also asks UI manager to show
> it to user, we queue it,
> letting user to deal with first one.. (or we delay the popup , say 1
> each 5 seconds).
>  
Perhaps the pre-debug window can display this queue - so that either the
pre-debug window is a Singleton, or at most one pre-debug window for
each source of "breakpoint".  Then any massive amounts of "halts" will
just scroll off-window and not block the UI when trying to fix the
problem.

> and finally, a queue should have some reasonable limit, after which we
> stop queuing , because again, user certainly won't be willing to waste
> his time dealing with 10000000 exceptions of same kind one by one. It
> doesn't makes sense anyways.
>
> In such case we can just ignore halt and let program continue (but
> increment some counter to show user how many of them are there).
> If exception is different (an Error) then on queue overflow, i think
> it should terminate the process with exception (but of course, special
> care must be taken if process is UI process).
> Of course making it too smart is pointless, because it is impossible
> to predict whether it is good idea
> to terminate process or letting it continue to run in case of exception.
> But for that we can have settings and options, to tune that at user's
> discretion, as well as default
> settings on a per-exception class base.
>
>  
>> anyhow, just musing....  -ben
>>
>>    
>
> i know by myself how annoying it can be (up to unresponsive image)
> and i think most of us is facing such situation time to time (heh..
> just yesterday we had it with Camillo while hacking ocompletion
> stuff).
> i learned to be careful and avoid such situations.. but sometimes it
> is hard and better tooling support will be helpful, no doubt.
>
>  
New users are not so good at being careful, and less frustrating if they
don't get overrun.
Thanks for your thoughts.


Reply | Threaded
Open this post in threaded view
|

Re: 'self halt' safety net

Mariano Martinez Peck
In reply to this post by Ben Coman


On Sat, Aug 4, 2012 at 4:11 AM, Ben Coman <[hidden email]> wrote:
As probably many newbies do from time to time, I am learning the system splattering 'self halt' around, and once again slipped one into the wrong place where I should have used 'haltOnce' and had a massive number of pre-debugger windows come up.  I managed to get it back this time with the user interrupt - but not always - and anyhow clearing so many debug windows is a pain.  So..... could 'self halt' be made to monitor the rate that the halt windows appear, and when more than some value from one of them (say five per second) it starts getting ignored and shows a dialog asking the user if they really meant this and enable danger mode, or if they screwed up and want to revert the method containing the suspect 'halt'.



it would be nice :)

 
Advanced features
+ button to close all debugger windows.

It is there in the meun:  Windows -> Close all debuggers
 
+ display the method showing the suspect 'self halt'

Another thought, it would be useful to be able to see a list of 'self halts' throughout the system and the timestamp of when they were insert, and perhaps distinguish whether they were inserted by the user or came when the package was loaded - and so providing more functionality than just using the Finder to 'search source'.


+9999 not only the halts but all the #flag:
 
Another thought, are there any plans for a "breakpoint" facility, so that I don't dirty a package by only inserting 'self halt' to aid debugging.  

it already exists. Right click on a method -> Add breakpoint
 
The effect would be just the same as a 'self halt' and even be compiled in to the bytecode as if it was but the source code remains pristine.  This could be represented by a symbol that could be dragged through a code window to anywhere immediately following a statement separator.  Perhaps the statement separator itself gets special significance as a point that could be activated as a debug point - and displayed using a big red font when it is active.

anyhow, just musing....  -ben




--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: 'self halt' safety net

Ben Coman
Mariano Martinez Peck wrote:

> On Sat, Aug 4, 2012 at 4:11 AM, Ben Coman <[hidden email]> wrote:
>
>  
>> Another thought, are there any plans for a "breakpoint" facility, so that
>> I don't dirty a package by only inserting 'self halt' to aid debugging.
>>    
>
>
> it already exists. Right click on a method -> Add breakpoint
>
>
>  
thanks Mariano.  Very nice to know.
That gets me half way there, however not being able to locate it
arbitrarily in the method will be awkward (even though even though
Smalltalk methods are typically short).

Reply | Threaded
Open this post in threaded view
|

Re: 'self halt' safety net

Sean P. DeNigris
Administrator
In reply to this post by Mariano Martinez Peck
Mariano Martinez Peck wrote
> Another thought, are there any plans for a "breakpoint" facility, so that
> I don't dirty a package by only inserting 'self halt' to aid debugging.
it already exists. Right click on a method -> Add breakpoint
I, too would love to have the features you suggest. However, as it stands, I would strongly advise against using breakpoints (someone definitely let me know, maybe this is not still a problem in 2.0). In my experience, they are incredibly buggy. Historically:
* if you add a breakpoint in one tool, and try to disable it in another, it may still be active; and who remembers what tool they enabled it in???
* there is very little feedback as to when a breakpoint is enabled
  - no icon in the browsers
  - the menu item was "toggle breakpoint" instead of dynamically "enable" vs. "disable"

In all, I found it very confusing to figure out when a breakpoint was enabled, and how to disable. Of course, anyway, these are not breakpoints as typically offered by an IDE, which can be attached to any statement, but only at the method level.

Cheers,
Sean
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: 'self halt' safety net

Fernando olivero-2
In reply to this post by Mariano Martinez Peck
What about a Nautilus plugin, that allows browsing all the methods
that send #halt, #flag:,#log:? (the "development" messages).

Since finding all the halts, doesn't seem something that needs to be
performed all the time, an optional Nautilus plugin would suffice.


Fernando

On Sat, Aug 4, 2012 at 3:02 PM, Sean P. DeNigris <[hidden email]> wrote:

>
> Mariano Martinez Peck wrote
>>
>>> Another thought, are there any plans for a "breakpoint" facility, so that
>>> I don't dirty a package by only inserting 'self halt' to aid debugging.
>> it already exists. Right click on a method -> Add breakpoint
>>
>
> I, too would love to have the features you suggest. However, as it stands, I
> would strongly advise against using breakpoints (someone definitely let me
> know, maybe this is not still a problem in 2.0). In my experience, they are
> incredibly buggy. Historically:
> * if you add a breakpoint in one tool, and try to disable it in another, it
> may still be active; and who remembers what tool they enabled it in???
> * there is very little feedback as to when a breakpoint is enabled
>   - no icon in the browsers
>   - the menu item was "toggle breakpoint" instead of dynamically "enable"
> vs. "disable"
>
> In all, I found it very confusing to figure out when a breakpoint was
> enabled, and how to disable. Of course, anyway, these are not breakpoints as
> typically offered by an IDE, which can be attached to any statement, but
> only at the method level.
>
> Cheers,
> Sean
>
>
>
> --
> View this message in context: http://forum.world.st/self-halt-safety-net-tp4643012p4643070.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>

Reply | Threaded
Open this post in threaded view
|

Re: 'self halt' safety net

Mariano Martinez Peck


On Sat, Aug 4, 2012 at 3:44 PM, Fernando Olivero <[hidden email]> wrote:
What about a Nautilus plugin, that allows browsing all the methods
that send #halt, #flag:,#log:? (the "development" messages).


That's a great idea. In fact, I remember being sit at my desk in Douai and doing that with Guille..
Guille, do you remember? 
 
Since finding all the halts, doesn't seem something that needs to be
performed all the time, an optional Nautilus plugin would suffice.


Fernando

On Sat, Aug 4, 2012 at 3:02 PM, Sean P. DeNigris <[hidden email]> wrote:
>
> Mariano Martinez Peck wrote
>>
>>> Another thought, are there any plans for a "breakpoint" facility, so that
>>> I don't dirty a package by only inserting 'self halt' to aid debugging.
>> it already exists. Right click on a method -> Add breakpoint
>>
>
> I, too would love to have the features you suggest. However, as it stands, I
> would strongly advise against using breakpoints (someone definitely let me
> know, maybe this is not still a problem in 2.0). In my experience, they are
> incredibly buggy. Historically:
> * if you add a breakpoint in one tool, and try to disable it in another, it
> may still be active; and who remembers what tool they enabled it in???
> * there is very little feedback as to when a breakpoint is enabled
>   - no icon in the browsers
>   - the menu item was "toggle breakpoint" instead of dynamically "enable"
> vs. "disable"
>
> In all, I found it very confusing to figure out when a breakpoint was
> enabled, and how to disable. Of course, anyway, these are not breakpoints as
> typically offered by an IDE, which can be attached to any statement, but
> only at the method level.
>
> Cheers,
> Sean
>
>
>
> --
> View this message in context: http://forum.world.st/self-halt-safety-net-tp4643012p4643070.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>




--
Mariano
http://marianopeck.wordpress.com

Reply | Threaded
Open this post in threaded view
|

Re: 'self halt' safety net

Benjamin Van Ryseghem (Pharo)
I do :)

A plugin that shows all the #flag: messages

Ben

On Aug 4, 2012, at 5:40 PM, Mariano Martinez Peck wrote:



On Sat, Aug 4, 2012 at 3:44 PM, Fernando Olivero <[hidden email]> wrote:
What about a Nautilus plugin, that allows browsing all the methods
that send #halt, #flag:,#log:? (the "development" messages).


That's a great idea. In fact, I remember being sit at my desk in Douai and doing that with Guille..
Guille, do you remember? 
 
Since finding all the halts, doesn't seem something that needs to be
performed all the time, an optional Nautilus plugin would suffice.


Fernando

On Sat, Aug 4, 2012 at 3:02 PM, Sean P. DeNigris <[hidden email]> wrote:
>
> Mariano Martinez Peck wrote
>>
>>> Another thought, are there any plans for a "breakpoint" facility, so that
>>> I don't dirty a package by only inserting 'self halt' to aid debugging.
>> it already exists. Right click on a method -> Add breakpoint
>>
>
> I, too would love to have the features you suggest. However, as it stands, I
> would strongly advise against using breakpoints (someone definitely let me
> know, maybe this is not still a problem in 2.0). In my experience, they are
> incredibly buggy. Historically:
> * if you add a breakpoint in one tool, and try to disable it in another, it
> may still be active; and who remembers what tool they enabled it in???
> * there is very little feedback as to when a breakpoint is enabled
>   - no icon in the browsers
>   - the menu item was "toggle breakpoint" instead of dynamically "enable"
> vs. "disable"
>
> In all, I found it very confusing to figure out when a breakpoint was
> enabled, and how to disable. Of course, anyway, these are not breakpoints as
> typically offered by an IDE, which can be attached to any statement, but
> only at the method level.
>
> Cheers,
> Sean
>
>
>
> --
> View this message in context: http://forum.world.st/self-halt-safety-net-tp4643012p4643070.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>




--
Mariano
http://marianopeck.wordpress.com


Reply | Threaded
Open this post in threaded view
|

Re: 'self halt' safety net

ccrraaiigg
In reply to this post by Ben Coman

     I also find using "self" is a bit of a roulette wheel... When I use
this tactic, I always say "3 halt" instead.


-C

--
Craig Latta
www.netjam.org/resume
+31   6 2757 7177
+ 1 415  287 3547 (no SMS)


Reply | Threaded
Open this post in threaded view
|

Re: 'self halt' safety net

Igor Stasenko
On 10 August 2012 14:41, Craig Latta <[hidden email]> wrote:
>
>      I also find using "self" is a bit of a roulette wheel... When I use
> this tactic, I always say "3 halt" instead.
>
in pharo you can use
Halt now.
which is imo the right way to do it..

but i so get used to type 'self halt' .. its hard to get rid of bad habits. :)

>
> -C
>
> --
> Craig Latta
> www.netjam.org/resume
> +31 6 2757 7177
> + 1 415 287 3547 (no SMS)
>
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: 'self halt' safety net

Sean P. DeNigris
Administrator
Igor Stasenko wrote
but i so get used to type 'self halt' .. its hard to get rid of bad habits. :)
Ha ha, I wanted to remove it but Steph wouldn't let me ;)
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: 'self halt' safety net

Dale Henrichs
Oh no! Now I'm going to have to port all of the `self halts` in my code, too:)

Dale

----- Original Message -----
| From: "Sean P. DeNigris" <[hidden email]>
| To: [hidden email]
| Sent: Friday, August 10, 2012 8:51:10 AM
| Subject: Re: [Pharo-project] 'self halt' safety net
|
|
| Igor Stasenko wrote
| >
| > but i so get used to type 'self halt' .. its hard to get rid of bad
| > habits. :)
| >
|
| Ha ha, I wanted to remove it but Steph wouldn't let me ;)
|
|
|
| --
| View this message in context:
| http://forum.world.st/self-halt-safety-net-tp4643012p4643771.html
| Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
|
|

Reply | Threaded
Open this post in threaded view
|

Re: 'self halt' safety net

EstebanLM
he, don't worry... that will not change soon :)

On Aug 10, 2012, at 6:01 PM, Dale Henrichs <[hidden email]> wrote:

> Oh no! Now I'm going to have to port all of the `self halts` in my code, too:)
>
> Dale
>
> ----- Original Message -----
> | From: "Sean P. DeNigris" <[hidden email]>
> | To: [hidden email]
> | Sent: Friday, August 10, 2012 8:51:10 AM
> | Subject: Re: [Pharo-project] 'self halt' safety net
> |
> |
> | Igor Stasenko wrote
> | >
> | > but i so get used to type 'self halt' .. its hard to get rid of bad
> | > habits. :)
> | >
> |
> | Ha ha, I wanted to remove it but Steph wouldn't let me ;)
> |
> |
> |
> | --
> | View this message in context:
> | http://forum.world.st/self-halt-safety-net-tp4643012p4643771.html
> | Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
> |
> |
>


Reply | Threaded
Open this post in threaded view
|

Re: 'self halt' safety net

Sean P. DeNigris
Administrator
In reply to this post by Igor Stasenko
Igor Stasenko wrote
in pharo you can use
Halt now.
which is imo the right way to do it..

but i so get used to type 'self halt' .. its hard to get rid of bad habits. :)
One little carrot to use "Halt now." is that it opens the debugger on the method with the halt in it instead of on Object>>halt, where you go to be punished for using "self halt" ;) I just found that out because after fighting to remove "self halt", I didn't get rid of my bad habit either, ha ha

- S
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: 'self halt' safety net

Ben Coman
Sean P. DeNigris wrote:

> Igor Stasenko wrote
>  
>> in pharo you can use
>> Halt now.
>> which is imo the right way to do it..
>>
>> but i so get used to type 'self halt' .. its hard to get rid of bad
>> habits. :)
>>
>>    
>
> One little carrot to use "Halt now." is that it opens the debugger on the
> method with the halt in it instead of on Object>>halt, where you go to be
> punished for using "self halt" ;) I just found that out because after
> fighting to remove "self halt", I didn't get rid of my bad habit either, ha
> ha
>
> - S
>
>  
Except that in Pharo 1.4 the 'Halt now' line is not highlighted upon
entering the debugger.  Probably not required to be fixed for 1.4 but
perhaps could be checked for 2.0.

cheers -ben


Reply | Threaded
Open this post in threaded view
|

Re: 'self halt' safety net

Ben Coman
In reply to this post by Igor Stasenko
Igor Stasenko wrote:

> On 4 August 2012 04:11, Ben Coman <[hidden email]> wrote:
>  
>> As probably many newbies do from time to time, I am learning the system
>> splattering 'self halt' around, and once again slipped one into the wrong
>> place where I should have used 'haltOnce' and had a massive number of
>> pre-debugger windows come up.  I managed to get it back this time with the
>> user interrupt - but not always - and anyhow clearing so many debug windows
>> is a pain.  So..... could 'self halt' be made to monitor the rate that the
>> halt windows appear, and when more than some value from one of them (say
>> five per second) it starts getting ignored and shows a dialog asking the
>> user if they really meant this and enable danger mode, or if they screwed up
>> and want to revert the method containing the suspect 'halt'.
>>
>>    
>
> If we look from user's perspective (not machine perspective), apparently
> it is pointless to throw so many messages at the user's face, because
> he cannot deal with them
> in meaningful manner at such rate.
> So, i think there should be something like following:
> - if exception requires a user interaction, we do show the popup, but
> meanwhile remember
> the exception which initiated it.
> - if there's next exception incoming and also asks UI manager to show
> it to user, we queue it,
> letting user to deal with first one.. (or we delay the popup , say 1
> each 5 seconds).
> and finally, a queue should have some reasonable limit, after which we
> stop queuing , because again, user certainly won't be willing to waste
> his time dealing with 10000000 exceptions of same kind one by one. It
> doesn't makes sense anyways.
>
> In such case we can just ignore halt and let program continue (but
> increment some counter to show user how many of them are there).
> If exception is different (an Error) then on queue overflow, i think
> it should terminate the process with exception (but of course, special
> care must be taken if process is UI process).
> Of course making it too smart is pointless, because it is impossible
> to predict whether it is good idea
> to terminate process or letting it continue to run in case of exception.
> But for that we can have settings and options, to tune that at user's
> discretion, as well as default
> settings on a per-exception class base.
>
>  
>> anyhow, just musing....  -ben
>>
>>    
>
> i know by myself how annoying it can be (up to unresponsive image)
> and i think most of us is facing such situation time to time (heh..
> just yesterday we had it with Camillo while hacking ocompletion
> stuff).
> i learned to be careful and avoid such situations.. but sometimes it
> is hard and better tooling support will be helpful, no doubt.
>
>  

Another use case that just happened to me.  This is not 'halt' related
but just a typo...  (which suddenly makes the whole system feel a bit
fragile)
Working on a small new feature in the drawing loop of Roassal, I would
guess "all" that I did was leave out a full stop at the end a line.  So
the image locked and crashed after about 20 seconds.  Unfortunately now
the image is crashing every time I try to open it.  Some mechanism to
throttle and temporarily ignore the error to allow me to rectify the
problem would have been immensely useful.  In this case, perhaps
something like blocking the main UI loop and presenting a modal window
of a very basic self contained text editor on the offending method.

At this moment, another immensely useful tool would be able to diff the
source code between a running image and an offline image, and import the
changes.
Is there any other way I might recover recent changes?  Previously I
have not had much luck mixing a new image with the changes file fromt he
crashed image.

regards -ben


----------------------------------------
THERE_BE_DRAGONS_HERE
MessageNotUnderstood: SmallInteger>>Transcript
25 August 2012 8:58:18.345 am

VM: Win32 - IX86 - 6.1 - CoInterpreter
VMMaker-oscog-EstebanLorenzano.158 uuid:
82eded98-68af-4c80-a472-4f6de293adcf May  1 2012,
StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.158 uuid:
82eded98-68af-4c80-a472-4f6de293adcf May  1 2012,
https://git.gitorious.org/cogvm/blessed.git Commit:
6aa3fd0f1188078d3167dec1a53031a61b97b688 Date: Tue May 1 20:28:14 2012
+0200 By: Esteban Lorenzano <[hidden email]>
Image: Pharo1.4 [Latest update: #14457]

SmallInteger(Object)>>doesNotUnderstand: #Transcript
    Receiver: 1
    Arguments and temporary variables:
        aMessage:     Transcript
        exception:     MessageNotUnderstood: SmallInteger>>Transcript
        resumeValue:     nil
    Receiver's instance variables:
1

ROOrthoVerticalLineShape>>lineSegmentsFor:
    Receiver: a ROOrthoVerticalLineShape
    Arguments and temporary variables:


---------------------------------------------------------------------
Sat Aug 25 09:15:38 2012


Error in the VM thread
Reason: out of memory



Hardware information:
        Manufacturer: Unknown
        Model: Unknown
        Number of processors: 4
        Page size: 4096

Memory Information (upon launch):
        Physical Memory Size: 4194303 kbytes
        Physical Memory Free: 4194303 kbytes
        Page File Size: 4194303 kbytes
        Page File Free: 4194303 kbytes
        Virtual Memory Size: 2097024 kbytes
        Virtual Memory Free: 2030848 kbytes
        Memory Load: 21 percent

Processor 0: AMD A10-4600M APU with Radeon(tm) HD Graphics  
        Identifier: AMD64 Family 21 Model 16 Stepping 1
        ~MHZ: 2295

Processor 1: AMD A10-4600M APU with Radeon(tm) HD Graphics  
        Identifier: AMD64 Family 21 Model 16 Stepping 1
        ~MHZ: 2295

Processor 2: AMD A10-4600M APU with Radeon(tm) HD Graphics  
        Identifier: AMD64 Family 21 Model 16 Stepping 1
        ~MHZ: 2295

Processor 3: AMD A10-4600M APU with Radeon(tm) HD Graphics  
        Identifier: AMD64 Family 21 Model 16 Stepping 1
        ~MHZ: 2295

Operating System: Windows 7 Home Premium (Build 7601 Service Pack 1)
        Registered Owner: Ben
        Registered Company: Toshiba
        SP major version: 1
        SP minor version: 0
        Suite mask: 300
        Product type: 1

Display Information:
        Graphics adapter name: AMD Radeon HD 7660G
        Primary monitor resolution: 1366 x 768

Device: RDPDD Chained DD
        Adapter String: ???
        Bios String: ???
        Chip Type: ???
        DAC Type: ???
        Memory Size: 0xFFFFFFFF

Driver Versions:
        RDPDD:

VM Version: Cog VM 4.0.0 (release) from May  1 2012
Compiler: gcc 4.5.2
Interpreter Build: CoInterpreter VMMaker-oscog-EstebanLorenzano.158 uuid: 82eded98-68af-4c80-a472-4f6de293adcf May  1 2012
Cogit Build: StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.158 uuid: 82eded98-68af-4c80-a472-4f6de293adcf May  1 2012
Source Version: https://git.gitorious.org/cogvm/blessed.git Commit: 6aa3fd0f1188078d3167dec1a53031a61b97b688 Date: Tue May 1 20:28:14 2012 +0200 By: Esteban Lorenzano <[hidden email]>

Current byte code: 208
Primitive index: 0

Loaded plugins:

Module information:
        00400000 - 005ec000: C:\Smalltalk\moose47-20120728-(StepCIM)\CogVM.exe
        04180000 - 04280000: CogCode
        695f0000 - 696d7000: C:\windows\system32\DDRAW.dll
        69770000 - 69838000: C:\windows\system32\OPENGL32.DLL
        6c240000 - 6c267000: C:\windows\system32\crtdll.dll
        719d0000 - 71a50000: C:\windows\system32\uxtheme.dll
        721c0000 - 72244000: C:\windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.17514_none_ec83dffa859149af\COMCTL32.dll
        72250000 - 7228c000: C:\windows\system32\OLEACC.dll
        72290000 - 722e1000: C:\windows\system32\WINSPOOL.DRV
        723d0000 - 723d9000: C:\windows\system32\VERSION.dll
        728f0000 - 72922000: C:\windows\system32\WINMM.dll
        729b0000 - 729e8000: C:\Program Files\Listary\ListaryHook32.dll
        730c0000 - 730d3000: C:\windows\system32\dwmapi.dll
        73150000 - 732ee000: C:\windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.DLL
        73640000 - 73662000: C:\windows\system32\GLU32.dll
        73670000 - 73695000: C:\windows\system32\dinput.dll
        73830000 - 73836000: C:\windows\system32\DCIMAN32.dll
        74170000 - 74177000: C:\windows\system32\WSOCK32.DLL
        74310000 - 74315000: C:\windows\system32\SHFolder.dll
        746c0000 - 746cc000: C:\windows\syswow64\CRYPTBASE.dll
        746d0000 - 74730000: C:\windows\syswow64\SspiCli.dll
        74730000 - 74742000: C:\windows\syswow64\DEVOBJ.dll
        74750000 - 74860000: C:\windows\syswow64\kernel32.dll
        74860000 - 74960000: C:\windows\syswow64\USER32.dll
        74960000 - 7496a000: C:\windows\syswow64\LPK.dll
        74970000 - 749b6000: C:\windows\syswow64\KERNELBASE.dll
        74a20000 - 74a47000: C:\windows\syswow64\CFGMGR32.dll
        74a50000 - 74bac000: C:\windows\syswow64\OLE32.dll
        74bb0000 - 74bb6000: C:\windows\syswow64\NSI.dll
        74bc0000 - 74c50000: C:\windows\syswow64\GDI32.dll
        74c50000 - 74ced000: C:\windows\syswow64\USP10.dll
        74cf0000 - 74d50000: C:\windows\system32\IMM32.DLL
        74f00000 - 74f19000: C:\windows\SysWOW64\sechost.dll
        750e0000 - 751ac000: C:\windows\syswow64\MSCTF.dll
        752d0000 - 75327000: C:\windows\syswow64\SHLWAPI.dll
        75380000 - 7542c000: C:\windows\syswow64\msvcrt.dll
        75430000 - 75465000: C:\windows\syswow64\WS2_32.dll
        754a0000 - 75540000: C:\windows\syswow64\ADVAPI32.DLL
        755d0000 - 7564b000: C:\windows\syswow64\COMDLG32.DLL
        75650000 - 757ed000: C:\windows\syswow64\SETUPAPI.dll
        757f0000 - 7643a000: C:\windows\syswow64\SHELL32.dll
        76590000 - 76680000: C:\windows\syswow64\RPCRT4.dll
        76690000 - 7671f000: C:\windows\syswow64\OLEAUT32.dll
        76720000 - 76725000: C:\windows\syswow64\psapi.dll
        76ff0000 - 77170000: C:\windows\SysWOW64\ntdll.dll

Primitive trace:
parameterAt:put:
parameterAt:put:
setGCBiasToGrowGCLimit:
setGCBiasToGrow:


Stack backtrace:
        [0041E90D] ??? + 125197 in CogVM.exe
        [00442022] ??? + 270370 in CogVM.exe
        [004443F9] ??? + 279545 in CogVM.exe
        [00445136] ??? + 282934 in CogVM.exe
        [0043F735] ??? + 259893 in CogVM.exe
        [0044BE49] ??? + 310857 in CogVM.exe
        [0044CC2C] ??? + 314412 in CogVM.exe
        [00537726] ??? + 1275686 in CogVM.exe
        [004010DB] ??? + 4315 in CogVM.exe
        [00401158] ??? + 4440 in CogVM.exe
        [7476339A] AcquireSRWLockExclusive + 18 in kernel32.dll
        [77029EF2] RtlInsertElementGenericTableAvl + 99 in ntdll.dll
        [77029EC5] RtlInsertElementGenericTableAvl + 54 in ntdll.dll
        [00000000] ??? + 0 in (null)


Smalltalk stack dump:
  0x1f00dc I SmalltalkImage>clearExternalObjects 71623188: a(n) SmalltalkImage
  0x1f0108 I SmalltalkImage>snapshot:andQuit: 71623188: a(n) SmalltalkImage
0x12105644 s [] in WorldState class>saveSession
0x121056a0 s BlockClosure>ensure:
0x120a7ed4 s CursorWithMask(Cursor)>showWhile:
0x120a7e68 s WorldState class>saveSession
0x121056fc s [] in ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent:
0x12105758 s BlockClosure>ensure:
0x120a7df8 s CursorWithMask(Cursor)>showWhile:
0x120a7d88 s ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent:
0x121057b4 s ToggleMenuItemMorph(MenuItemMorph)>mouseUp:
0x12105810 s ToggleMenuItemMorph(MenuItemMorph)>handleMouseUp:
0x1210586c s MouseButtonEvent>sentTo:
0x121058c8 s ToggleMenuItemMorph(Morph)>handleEvent:
0x12105924 s MorphicEventDispatcher>dispatchDefault:with:
0x12105980 s MorphicEventDispatcher>dispatchEvent:with:
0x121059dc s ToggleMenuItemMorph(Morph)>processEvent:using:
0x12105a38 s MorphicEventDispatcher>dispatchDefault:with:
0x12105a94 s MorphicEventDispatcher>dispatchEvent:with:
0x12105af0 s MenuMorph(Morph)>processEvent:using:
0x12105b4c s MenuMorph(Morph)>processEvent:
0x12105ba8 s MenuMorph>handleFocusEvent:
0x12105c04 s [] in HandMorph>sendFocusEvent:to:clear:
0x12105c60 s [] in PasteUpMorph>becomeActiveDuring:
0x12105cbc s BlockClosure>on:do:
0x120a7c10 s PasteUpMorph>becomeActiveDuring:
0x120a7b98 s HandMorph>sendFocusEvent:to:clear:
0x12105d18 s HandMorph>sendEvent:focus:clear:
0x120a7b24 s HandMorph>sendMouseEvent:
0x12105d74 s HandMorph>handleEvent:
0x12105dd0 s HandMorph>processEvents
0x12105e2c s [] in WorldState>doOneCycleNowFor:
0x12105e88 s Array(SequenceableCollection)>do:
0x12105ee4 s WorldState>handsDo:
0x120a79cc s WorldState>doOneCycleNowFor:
0x12105f40 s WorldState>doOneCycleFor:
0x12105f9c s PasteUpMorph>doOneCycle
 0xb289e94 s [] in MorphicUIManager>spawnNewProcess
 0xb289e10 s [] in BlockClosure>newProcess

Reply | Threaded
Open this post in threaded view
|

Re: 'self halt' safety net

Igor Stasenko
you can open .changes file in another image to rescue your code.
also you can patch the image's bytecode to avoid entering an offending method
(like a method which enters the drawing , just see its bytecode in
another image,
and the find same byte sequence in crashing image, and put return self bytecode)

On 25 August 2012 03:42, Ben Coman <[hidden email]> wrote:

> Igor Stasenko wrote:
>>
>> On 4 August 2012 04:11, Ben Coman <[hidden email]> wrote:
>>
>>>
>>> As probably many newbies do from time to time, I am learning the system
>>> splattering 'self halt' around, and once again slipped one into the wrong
>>> place where I should have used 'haltOnce' and had a massive number of
>>> pre-debugger windows come up.  I managed to get it back this time with
>>> the
>>> user interrupt - but not always - and anyhow clearing so many debug
>>> windows
>>> is a pain.  So..... could 'self halt' be made to monitor the rate that
>>> the
>>> halt windows appear, and when more than some value from one of them (say
>>> five per second) it starts getting ignored and shows a dialog asking the
>>> user if they really meant this and enable danger mode, or if they screwed
>>> up
>>> and want to revert the method containing the suspect 'halt'.
>>>
>>>
>>
>>
>> If we look from user's perspective (not machine perspective), apparently
>> it is pointless to throw so many messages at the user's face, because
>> he cannot deal with them
>> in meaningful manner at such rate.
>> So, i think there should be something like following:
>> - if exception requires a user interaction, we do show the popup, but
>> meanwhile remember
>> the exception which initiated it.
>> - if there's next exception incoming and also asks UI manager to show
>> it to user, we queue it,
>> letting user to deal with first one.. (or we delay the popup , say 1
>> each 5 seconds).
>> and finally, a queue should have some reasonable limit, after which we
>> stop queuing , because again, user certainly won't be willing to waste
>> his time dealing with 10000000 exceptions of same kind one by one. It
>> doesn't makes sense anyways.
>>
>> In such case we can just ignore halt and let program continue (but
>> increment some counter to show user how many of them are there).
>> If exception is different (an Error) then on queue overflow, i think
>> it should terminate the process with exception (but of course, special
>> care must be taken if process is UI process).
>> Of course making it too smart is pointless, because it is impossible
>> to predict whether it is good idea
>> to terminate process or letting it continue to run in case of exception.
>> But for that we can have settings and options, to tune that at user's
>> discretion, as well as default
>> settings on a per-exception class base.
>>
>>
>>>
>>> anyhow, just musing....  -ben
>>>
>>>
>>
>>
>> i know by myself how annoying it can be (up to unresponsive image)
>> and i think most of us is facing such situation time to time (heh..
>> just yesterday we had it with Camillo while hacking ocompletion
>> stuff).
>> i learned to be careful and avoid such situations.. but sometimes it
>> is hard and better tooling support will be helpful, no doubt.
>>
>>
>
>
>
> Another use case that just happened to me.  This is not 'halt' related but
> just a typo...  (which suddenly makes the whole system feel a bit fragile)
> Working on a small new feature in the drawing loop of Roassal, I would guess
> "all" that I did was leave out a full stop at the end a line.  So the image
> locked and crashed after about 20 seconds.  Unfortunately now the image is
> crashing every time I try to open it.  Some mechanism to throttle and
> temporarily ignore the error to allow me to rectify the problem would have
> been immensely useful.  In this case, perhaps something like blocking the
> main UI loop and presenting a modal window of a very basic self contained
> text editor on the offending method.
> At this moment, another immensely useful tool would be able to diff the
> source code between a running image and an offline image, and import the
> changes.
> Is there any other way I might recover recent changes?  Previously I have
> not had much luck mixing a new image with the changes file fromt he crashed
> image.
>
> regards -ben
>
>
> ----------------------------------------
> THERE_BE_DRAGONS_HERE
> MessageNotUnderstood: SmallInteger>>Transcript
> 25 August 2012 8:58:18.345 am
>
> VM: Win32 - IX86 - 6.1 - CoInterpreter VMMaker-oscog-EstebanLorenzano.158
> uuid: 82eded98-68af-4c80-a472-4f6de293adcf May  1 2012,
> StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.158 uuid:
> 82eded98-68af-4c80-a472-4f6de293adcf May  1 2012,
> https://git.gitorious.org/cogvm/blessed.git Commit:
> 6aa3fd0f1188078d3167dec1a53031a61b97b688 Date: Tue May 1 20:28:14 2012 +0200
> By: Esteban Lorenzano <[hidden email]>
> Image: Pharo1.4 [Latest update: #14457]
>
> SmallInteger(Object)>>doesNotUnderstand: #Transcript
>    Receiver: 1
>    Arguments and temporary variables:
>        aMessage:     Transcript
>        exception:     MessageNotUnderstood: SmallInteger>>Transcript
>        resumeValue:     nil
>    Receiver's instance variables:
> 1
>
> ROOrthoVerticalLineShape>>lineSegmentsFor:
>    Receiver: a ROOrthoVerticalLineShape
>    Arguments and temporary variables:
>
>
> ---------------------------------------------------------------------
> Sat Aug 25 09:15:38 2012
>
>
> Error in the VM thread
> Reason: out of memory
>
>
>
> Hardware information:
>         Manufacturer: Unknown
>         Model: Unknown
>         Number of processors: 4
>         Page size: 4096
>
> Memory Information (upon launch):
>         Physical Memory Size: 4194303 kbytes
>         Physical Memory Free: 4194303 kbytes
>         Page File Size: 4194303 kbytes
>         Page File Free: 4194303 kbytes
>         Virtual Memory Size: 2097024 kbytes
>         Virtual Memory Free: 2030848 kbytes
>         Memory Load: 21 percent
>
> Processor 0: AMD A10-4600M APU with Radeon(tm) HD Graphics
>         Identifier: AMD64 Family 21 Model 16 Stepping 1
>         ~MHZ: 2295
>
> Processor 1: AMD A10-4600M APU with Radeon(tm) HD Graphics
>         Identifier: AMD64 Family 21 Model 16 Stepping 1
>         ~MHZ: 2295
>
> Processor 2: AMD A10-4600M APU with Radeon(tm) HD Graphics
>         Identifier: AMD64 Family 21 Model 16 Stepping 1
>         ~MHZ: 2295
>
> Processor 3: AMD A10-4600M APU with Radeon(tm) HD Graphics
>         Identifier: AMD64 Family 21 Model 16 Stepping 1
>         ~MHZ: 2295
>
> Operating System: Windows 7 Home Premium (Build 7601 Service Pack 1)
>         Registered Owner: Ben
>         Registered Company: Toshiba
>         SP major version: 1
>         SP minor version: 0
>         Suite mask: 300
>         Product type: 1
>
> Display Information:
>         Graphics adapter name: AMD Radeon HD 7660G
>         Primary monitor resolution: 1366 x 768
>
> Device: RDPDD Chained DD
>         Adapter String: ???
>         Bios String: ???
>         Chip Type: ???
>         DAC Type: ???
>         Memory Size: 0xFFFFFFFF
>
> Driver Versions:
>         RDPDD:
>
> VM Version: Cog VM 4.0.0 (release) from May  1 2012
> Compiler: gcc 4.5.2
> Interpreter Build: CoInterpreter VMMaker-oscog-EstebanLorenzano.158 uuid:
> 82eded98-68af-4c80-a472-4f6de293adcf May  1 2012
> Cogit Build: StackToRegisterMappingCogit VMMaker-oscog-EstebanLorenzano.158
> uuid: 82eded98-68af-4c80-a472-4f6de293adcf May  1 2012
> Source Version: https://git.gitorious.org/cogvm/blessed.git Commit:
> 6aa3fd0f1188078d3167dec1a53031a61b97b688 Date: Tue May 1 20:28:14 2012 +0200
> By: Esteban Lorenzano <[hidden email]>
>
> Current byte code: 208
> Primitive index: 0
>
> Loaded plugins:
>
> Module information:
>         00400000 - 005ec000:
> C:\Smalltalk\moose47-20120728-(StepCIM)\CogVM.exe
>         04180000 - 04280000: CogCode
>         695f0000 - 696d7000: C:\windows\system32\DDRAW.dll
>         69770000 - 69838000: C:\windows\system32\OPENGL32.DLL
>         6c240000 - 6c267000: C:\windows\system32\crtdll.dll
>         719d0000 - 71a50000: C:\windows\system32\uxtheme.dll
>         721c0000 - 72244000:
> C:\windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.17514_none_ec83dffa859149af\COMCTL32.dll
>         72250000 - 7228c000: C:\windows\system32\OLEACC.dll
>         72290000 - 722e1000: C:\windows\system32\WINSPOOL.DRV
>         723d0000 - 723d9000: C:\windows\system32\VERSION.dll
>         728f0000 - 72922000: C:\windows\system32\WINMM.dll
>         729b0000 - 729e8000: C:\Program Files\Listary\ListaryHook32.dll
>         730c0000 - 730d3000: C:\windows\system32\dwmapi.dll
>         73150000 - 732ee000:
> C:\windows\WinSxS\x86_microsoft.windows.common-controls_6595b64144ccf1df_6.0.7601.17514_none_41e6975e2bd6f2b2\comctl32.DLL
>         73640000 - 73662000: C:\windows\system32\GLU32.dll
>         73670000 - 73695000: C:\windows\system32\dinput.dll
>         73830000 - 73836000: C:\windows\system32\DCIMAN32.dll
>         74170000 - 74177000: C:\windows\system32\WSOCK32.DLL
>         74310000 - 74315000: C:\windows\system32\SHFolder.dll
>         746c0000 - 746cc000: C:\windows\syswow64\CRYPTBASE.dll
>         746d0000 - 74730000: C:\windows\syswow64\SspiCli.dll
>         74730000 - 74742000: C:\windows\syswow64\DEVOBJ.dll
>         74750000 - 74860000: C:\windows\syswow64\kernel32.dll
>         74860000 - 74960000: C:\windows\syswow64\USER32.dll
>         74960000 - 7496a000: C:\windows\syswow64\LPK.dll
>         74970000 - 749b6000: C:\windows\syswow64\KERNELBASE.dll
>         74a20000 - 74a47000: C:\windows\syswow64\CFGMGR32.dll
>         74a50000 - 74bac000: C:\windows\syswow64\OLE32.dll
>         74bb0000 - 74bb6000: C:\windows\syswow64\NSI.dll
>         74bc0000 - 74c50000: C:\windows\syswow64\GDI32.dll
>         74c50000 - 74ced000: C:\windows\syswow64\USP10.dll
>         74cf0000 - 74d50000: C:\windows\system32\IMM32.DLL
>         74f00000 - 74f19000: C:\windows\SysWOW64\sechost.dll
>         750e0000 - 751ac000: C:\windows\syswow64\MSCTF.dll
>         752d0000 - 75327000: C:\windows\syswow64\SHLWAPI.dll
>         75380000 - 7542c000: C:\windows\syswow64\msvcrt.dll
>         75430000 - 75465000: C:\windows\syswow64\WS2_32.dll
>         754a0000 - 75540000: C:\windows\syswow64\ADVAPI32.DLL
>         755d0000 - 7564b000: C:\windows\syswow64\COMDLG32.DLL
>         75650000 - 757ed000: C:\windows\syswow64\SETUPAPI.dll
>         757f0000 - 7643a000: C:\windows\syswow64\SHELL32.dll
>         76590000 - 76680000: C:\windows\syswow64\RPCRT4.dll
>         76690000 - 7671f000: C:\windows\syswow64\OLEAUT32.dll
>         76720000 - 76725000: C:\windows\syswow64\psapi.dll
>         76ff0000 - 77170000: C:\windows\SysWOW64\ntdll.dll
>
> Primitive trace:
> parameterAt:put:
> parameterAt:put:
> setGCBiasToGrowGCLimit:
> setGCBiasToGrow:
>
>
> Stack backtrace:
>         [0041E90D] ??? + 125197 in CogVM.exe
>         [00442022] ??? + 270370 in CogVM.exe
>         [004443F9] ??? + 279545 in CogVM.exe
>         [00445136] ??? + 282934 in CogVM.exe
>         [0043F735] ??? + 259893 in CogVM.exe
>         [0044BE49] ??? + 310857 in CogVM.exe
>         [0044CC2C] ??? + 314412 in CogVM.exe
>         [00537726] ??? + 1275686 in CogVM.exe
>         [004010DB] ??? + 4315 in CogVM.exe
>         [00401158] ??? + 4440 in CogVM.exe
>         [7476339A] AcquireSRWLockExclusive + 18 in kernel32.dll
>         [77029EF2] RtlInsertElementGenericTableAvl + 99 in ntdll.dll
>         [77029EC5] RtlInsertElementGenericTableAvl + 54 in ntdll.dll
>         [00000000] ??? + 0 in (null)
>
>
> Smalltalk stack dump:
>   0x1f00dc I SmalltalkImage>clearExternalObjects 71623188: a(n)
> SmalltalkImage
>   0x1f0108 I SmalltalkImage>snapshot:andQuit: 71623188: a(n) SmalltalkImage
> 0x12105644 s [] in WorldState class>saveSession
> 0x121056a0 s BlockClosure>ensure:
> 0x120a7ed4 s CursorWithMask(Cursor)>showWhile:
> 0x120a7e68 s WorldState class>saveSession
> 0x121056fc s [] in ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent:
> 0x12105758 s BlockClosure>ensure:
> 0x120a7df8 s CursorWithMask(Cursor)>showWhile:
> 0x120a7d88 s ToggleMenuItemMorph(MenuItemMorph)>invokeWithEvent:
> 0x121057b4 s ToggleMenuItemMorph(MenuItemMorph)>mouseUp:
> 0x12105810 s ToggleMenuItemMorph(MenuItemMorph)>handleMouseUp:
> 0x1210586c s MouseButtonEvent>sentTo:
> 0x121058c8 s ToggleMenuItemMorph(Morph)>handleEvent:
> 0x12105924 s MorphicEventDispatcher>dispatchDefault:with:
> 0x12105980 s MorphicEventDispatcher>dispatchEvent:with:
> 0x121059dc s ToggleMenuItemMorph(Morph)>processEvent:using:
> 0x12105a38 s MorphicEventDispatcher>dispatchDefault:with:
> 0x12105a94 s MorphicEventDispatcher>dispatchEvent:with:
> 0x12105af0 s MenuMorph(Morph)>processEvent:using:
> 0x12105b4c s MenuMorph(Morph)>processEvent:
> 0x12105ba8 s MenuMorph>handleFocusEvent:
> 0x12105c04 s [] in HandMorph>sendFocusEvent:to:clear:
> 0x12105c60 s [] in PasteUpMorph>becomeActiveDuring:
> 0x12105cbc s BlockClosure>on:do:
> 0x120a7c10 s PasteUpMorph>becomeActiveDuring:
> 0x120a7b98 s HandMorph>sendFocusEvent:to:clear:
> 0x12105d18 s HandMorph>sendEvent:focus:clear:
> 0x120a7b24 s HandMorph>sendMouseEvent:
> 0x12105d74 s HandMorph>handleEvent:
> 0x12105dd0 s HandMorph>processEvents
> 0x12105e2c s [] in WorldState>doOneCycleNowFor:
> 0x12105e88 s Array(SequenceableCollection)>do:
> 0x12105ee4 s WorldState>handsDo:
> 0x120a79cc s WorldState>doOneCycleNowFor:
> 0x12105f40 s WorldState>doOneCycleFor:
> 0x12105f9c s PasteUpMorph>doOneCycle
>  0xb289e94 s [] in MorphicUIManager>spawnNewProcess
>  0xb289e10 s [] in BlockClosure>newProcess
>
>



--
Best regards,
Igor Stasenko.

Reply | Threaded
Open this post in threaded view
|

Re: 'self halt' safety net

Ben Coman





Igor Stasenko wrote:
> you can open .changes file in another image to rescue your code.
>  
Thanks Igor.  I gave that a go but couldn't work it out.  I tried the
following:  Unzipped a fresh image, copied the .changes file into the
folder to overwrite the existing .changes file, then after starting the
image tried (World > Tools > Recover lost changes...)  but I get
"Information: this image has never been saved since changes were
compressed."  Saving the image seems to empty the .changes file.  I
could not find another way.  Is there something else I should be doing?
> also you can patch the image's bytecode to avoid entering an offending method
> (like a method which enters the drawing , just see its bytecode in
> another image,
> and the find same byte sequence in crashing image, and put return self bytecode)
>  
Thanks, but that is beyond my capability at the moment.  Probably
wishing for too much, but ideally some mechanism might use info from the
debug.log to do this automatically.

> On 25 August 2012 03:42, Ben Coman <[hidden email]> wrote:
>  
>> Igor Stasenko wrote:
>>    
>>> On 4 August 2012 04:11, Ben Coman <[hidden email]> wrote:
>>>
>>>      
>>>> As probably many newbies do from time to time, I am learning the system
>>>> splattering 'self halt' around, and once again slipped one into the wrong
>>>> place where I should have used 'haltOnce' and had a massive number of
>>>> pre-debugger windows come up.  I managed to get it back this time with
>>>> the
>>>> user interrupt - but not always - and anyhow clearing so many debug
>>>> windows
>>>> is a pain.  So..... could 'self halt' be made to monitor the rate that
>>>> the
>>>> halt windows appear, and when more than some value from one of them (say
>>>> five per second) it starts getting ignored and shows a dialog asking the
>>>> user if they really meant this and enable danger mode, or if they screwed
>>>> up
>>>> and want to revert the method containing the suspect 'halt'.
>>>>
>>>>
>>>>        
>>> If we look from user's perspective (not machine perspective), apparently
>>> it is pointless to throw so many messages at the user's face, because
>>> he cannot deal with them
>>> in meaningful manner at such rate.
>>> So, i think there should be something like following:
>>> - if exception requires a user interaction, we do show the popup, but
>>> meanwhile remember
>>> the exception which initiated it.
>>> - if there's next exception incoming and also asks UI manager to show
>>> it to user, we queue it,
>>> letting user to deal with first one.. (or we delay the popup , say 1
>>> each 5 seconds).
>>> and finally, a queue should have some reasonable limit, after which we
>>> stop queuing , because again, user certainly won't be willing to waste
>>> his time dealing with 10000000 exceptions of same kind one by one. It
>>> doesn't makes sense anyways.
>>>
>>> In such case we can just ignore halt and let program continue (but
>>> increment some counter to show user how many of them are there).
>>> If exception is different (an Error) then on queue overflow, i think
>>> it should terminate the process with exception (but of course, special
>>> care must be taken if process is UI process).
>>> Of course making it too smart is pointless, because it is impossible
>>> to predict whether it is good idea
>>> to terminate process or letting it continue to run in case of exception.
>>> But for that we can have settings and options, to tune that at user's
>>> discretion, as well as default
>>> settings on a per-exception class base.
>>>
>>>
>>>      
>>>> anyhow, just musing....  -ben
>>>>
>>>>
>>>>        
>>> i know by myself how annoying it can be (up to unresponsive image)
>>> and i think most of us is facing such situation time to time (heh..
>>> just yesterday we had it with Camillo while hacking ocompletion
>>> stuff).
>>> i learned to be careful and avoid such situations.. but sometimes it
>>> is hard and better tooling support will be helpful, no doubt.
>>>
>>>
>>>      
>>
>> Another use case that just happened to me.  This is not 'halt' related but
>> just a typo...  (which suddenly makes the whole system feel a bit fragile)
>> Working on a small new feature in the drawing loop of Roassal, I would guess
>> "all" that I did was leave out a full stop at the end a line.  So the image
>> locked and crashed after about 20 seconds.  Unfortunately now the image is
>> crashing every time I try to open it.  Some mechanism to throttle and
>> temporarily ignore the error to allow me to rectify the problem would have
>> been immensely useful.  In this case, perhaps something like blocking the
>> main UI loop and presenting a modal window of a very basic self contained
>> text editor on the offending method.
>> At this moment, another immensely useful tool would be able to diff the
>> source code between a running image and an offline image, and import the
>> changes.
>> Is there any other way I might recover recent changes?  Previously I have
>> not had much luck mixing a new image with the changes file fromt he crashed
>> image.
>>
>> regards -ben
>>
>>    
[Debug logs deleted]

Reply | Threaded
Open this post in threaded view
|

Re: 'self halt' safety net

Eliot Miranda-2


On Mon, Aug 27, 2012 at 8:44 AM, Ben Coman <[hidden email]> wrote:





Igor Stasenko wrote:
you can open .changes file in another image to rescue your code.
 
Thanks Igor.  I gave that a go but couldn't work it out.  I tried the following:  Unzipped a fresh image, copied the .changes file into the folder to overwrite the existing .changes file, then after starting the image tried (World > Tools > Recover lost changes...)  but I get "Information: this image has never been saved since changes were compressed."  Saving the image seems to empty the .changes file.  I could not find another way.  Is there something else I should be doing?

Ben, your changes were in the .changes file that you overwrote.  You should have either
a) unpacked the second image/changes in a different directory
b) renamed the changes file you wanted to recover before unpacking the second image/changes
c) unpacked the second image/changes with different names
d) anything else that avoids overwriting the changes file you wanted to recover.

its gone now unless you have a recent backup

also you can patch the image's bytecode to avoid entering an offending method
(like a method which enters the drawing , just see its bytecode in
another image,
and the find same byte sequence in crashing image, and put return self bytecode)
 
Thanks, but that is beyond my capability at the moment.  Probably wishing for too much, but ideally some mechanism might use info from the debug.log to do this automatically.
On 25 August 2012 03:42, Ben Coman <[hidden email]> wrote:
 
Igor Stasenko wrote:
   
On 4 August 2012 04:11, Ben Coman <[hidden email]> wrote:

     
As probably many newbies do from time to time, I am learning the system
splattering 'self halt' around, and once again slipped one into the wrong
place where I should have used 'haltOnce' and had a massive number of
pre-debugger windows come up.  I managed to get it back this time with
the
user interrupt - but not always - and anyhow clearing so many debug
windows
is a pain.  So..... could 'self halt' be made to monitor the rate that
the
halt windows appear, and when more than some value from one of them (say
five per second) it starts getting ignored and shows a dialog asking the
user if they really meant this and enable danger mode, or if they screwed
up
and want to revert the method containing the suspect 'halt'.


       
If we look from user's perspective (not machine perspective), apparently
it is pointless to throw so many messages at the user's face, because
he cannot deal with them
in meaningful manner at such rate.
So, i think there should be something like following:
- if exception requires a user interaction, we do show the popup, but
meanwhile remember
the exception which initiated it.
- if there's next exception incoming and also asks UI manager to show
it to user, we queue it,
letting user to deal with first one.. (or we delay the popup , say 1
each 5 seconds).
and finally, a queue should have some reasonable limit, after which we
stop queuing , because again, user certainly won't be willing to waste
his time dealing with 10000000 exceptions of same kind one by one. It
doesn't makes sense anyways.

In such case we can just ignore halt and let program continue (but
increment some counter to show user how many of them are there).
If exception is different (an Error) then on queue overflow, i think
it should terminate the process with exception (but of course, special
care must be taken if process is UI process).
Of course making it too smart is pointless, because it is impossible
to predict whether it is good idea
to terminate process or letting it continue to run in case of exception.
But for that we can have settings and options, to tune that at user's
discretion, as well as default
settings on a per-exception class base.


     
anyhow, just musing....  -ben


       
i know by myself how annoying it can be (up to unresponsive image)
and i think most of us is facing such situation time to time (heh..
just yesterday we had it with Camillo while hacking ocompletion
stuff).
i learned to be careful and avoid such situations.. but sometimes it
is hard and better tooling support will be helpful, no doubt.


     

Another use case that just happened to me.  This is not 'halt' related but
just a typo...  (which suddenly makes the whole system feel a bit fragile)
Working on a small new feature in the drawing loop of Roassal, I would guess
"all" that I did was leave out a full stop at the end a line.  So the image
locked and crashed after about 20 seconds.  Unfortunately now the image is
crashing every time I try to open it.  Some mechanism to throttle and
temporarily ignore the error to allow me to rectify the problem would have
been immensely useful.  In this case, perhaps something like blocking the
main UI loop and presenting a modal window of a very basic self contained
text editor on the offending method.
At this moment, another immensely useful tool would be able to diff the
source code between a running image and an offline image, and import the
changes.
Is there any other way I might recover recent changes?  Previously I have
not had much luck mixing a new image with the changes file fromt he crashed
image.

regards -ben

   
[Debug logs deleted]




--
best,
Eliot

12