[Pharo-project] Recursive calls hang image
My image hung after executing: categoryName := $- asParser negate plus flatten, ($- asParser, #any asParser star flatten) optional star. categoryName parse: 'SuperMe'. On the Moose list [1], Lukas pointed out the bug in my code which led to direct recursion, and that hanging under this circumstance was a bug in Pharo. Is this a known bug, or shall I file an issue? [1] http://forum.world.st/PetitParser-crash-td3725129.html -- View this message in context: http://forum.world.st/Recursive-calls-hang-image-tp3728055p3728055.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Hangs? Well it is normal, since it is busy evaluating an infinite recursion, right? :) So, as far as i understand the problem is that you cannot interrupt it, by pressing Alt-. (or Cmd-. on macs)? Because there's little what could be done with code which goes into recursion, actually only one thing - fix it. :) On 8 August 2011 21:47, Sean P. DeNigris <sean@clipperadams.com> wrote:
My image hung after executing: Â categoryName := $- asParser negate plus flatten, ($- asParser, #any asParser star flatten) optional star. Â categoryName parse: 'SuperMe'.
On the Moose list [1], Lukas pointed out the bug in my code which led to direct recursion, and that hanging under this circumstance was a bug in Pharo. Is this a known bug, or shall I file an issue?
[1] http://forum.world.st/PetitParser-crash-td3725129.html
-- View this message in context: http://forum.world.st/Recursive-calls-hang-image-tp3728055p3728055.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko AKA sig.
Igor Stasenko wrote:
the problem is that you cannot interrupt it, by pressing Alt-. (or Cmd-. on macs)?
Right, smart ass ;-) -- View this message in context: http://forum.world.st/Recursive-calls-hang-image-tp3728055p3728159.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 8 August 2011 22:17, Sean P. DeNigris <sean@clipperadams.com> wrote:
Igor Stasenko wrote:
the problem is that you cannot interrupt it, by pressing Alt-. (or Cmd-. on macs)?
Right, smart ass ;-)
Well, it works for me, if i press it multiple times :) InputEventFetcher default eventHandlers an OrderedCollection(an InputEventSensor an UserInterruptHandler) So, all logic whether interrupt the process or not, is in #handleUserInterrupt i think we should change it: toInterrupt := Processor preemptedProcess. "Only interrupt processes which are potentially blocking the UI" toInterrupt priority < UIManager default uiProcess priority ifTrue: [toInterrupt := Project uiProcess]. "Fork at lower priority to avoid interrupting system-critical processes" toInterrupt debugWithTitle: 'User Interrupt'] forkAt: Processor activeProcess priority -1 the #preemptedProcess is not works, because it actually tries to guess, which process was preempted, instead of knowing it exactly. What i think we should do is to extend the UserInterruptHandler to a) have a registry of system-critical processes , which should never be interrupted: this is Delay, Event fetcher, interrupt handler, weak finalizer, idle process All those facilities should register themselves in UserInterruptHandler whenever they deciding to start or restart their process. b) interrupt the first process, not found in (a), going from higher priority to lower. Then if you press the cmd-. multiple times, you will be able to interrupt anything which is not system-critical. Because there is no reliable way to detect a processor hog process, unless you running CPU watcher and gather statistics on CPU consumption rates. Stopping a process which was running just before current one is like shooting in the clear sky in hope that duck will teleport right on the path of your bullet :) -- Best regards, Igor Stasenko AKA sig.
Another thing, which i think we should try is to put interrupt handler ahead of event sensor handler (because it should take priority above anything else), so InputEventFetcher default eventHandlers should read: an OrderedCollection(an UserInterruptHandler an InputEventSensor ) but not
an OrderedCollection(an InputEventSensor an UserInterruptHandler)
On 8 August 2011 22:42, Igor Stasenko <siguctua@gmail.com> wrote:
On 8 August 2011 22:17, Sean P. DeNigris <sean@clipperadams.com> wrote:
Igor Stasenko wrote:
the problem is that you cannot interrupt it, by pressing Alt-. (or Cmd-. on macs)?
Right, smart ass ;-)
Well, it works for me, if i press it multiple times :)
InputEventFetcher default eventHandlers
an OrderedCollection(an InputEventSensor an UserInterruptHandler)
So, all logic whether interrupt the process or not, is in #handleUserInterrupt
i think we should change it:
            toInterrupt := Processor preemptedProcess.             "Only interrupt processes which are potentially blocking the UI"             toInterrupt priority <  UIManager default uiProcess priority ifTrue: [toInterrupt := Project uiProcess].
            "Fork at lower priority to avoid interrupting system-critical processes"             toInterrupt debugWithTitle: 'User Interrupt']                 forkAt: Processor activeProcess priority -1
the #preemptedProcess is not works, because it actually tries to guess, which process was preempted, instead of knowing it exactly.
What i think we should do is to extend the UserInterruptHandler to
 a) have a registry of system-critical processes , which should never be interrupted: this is Delay, Event fetcher, interrupt handler,  weak finalizer, idle process All those facilities should register themselves in UserInterruptHandler whenever they deciding to start or restart their process.
 b) interrupt the first process, not found in (a), going from higher priority to lower. Then if you press the cmd-. multiple times, you will be able to interrupt anything which is not system-critical.
Because there is no reliable way to detect a processor hog process, unless you running CPU watcher and gather statistics on CPU consumption rates. Stopping a process which was running just before current one is like shooting in the clear sky in hope that duck will teleport right on the path of your bullet :)
-- Best regards, Igor Stasenko AKA sig.
-- Best regards, Igor Stasenko AKA sig.
igor I like the idea. It provides a solution not depending on the scheduler strategy. We should implement it :) Stef On Aug 8, 2011, at 10:42 PM, Igor Stasenko wrote:
On 8 August 2011 22:17, Sean P. DeNigris <sean@clipperadams.com> wrote:
Igor Stasenko wrote:
the problem is that you cannot interrupt it, by pressing Alt-. (or Cmd-. on macs)?
Right, smart ass ;-)
Well, it works for me, if i press it multiple times :)
InputEventFetcher default eventHandlers
an OrderedCollection(an InputEventSensor an UserInterruptHandler)
So, all logic whether interrupt the process or not, is in #handleUserInterrupt
i think we should change it:
toInterrupt := Processor preemptedProcess. "Only interrupt processes which are potentially blocking the UI" toInterrupt priority < UIManager default uiProcess priority ifTrue: [toInterrupt := Project uiProcess].
"Fork at lower priority to avoid interrupting system-critical processes" toInterrupt debugWithTitle: 'User Interrupt'] forkAt: Processor activeProcess priority -1
the #preemptedProcess is not works, because it actually tries to guess, which process was preempted, instead of knowing it exactly.
What i think we should do is to extend the UserInterruptHandler to
a) have a registry of system-critical processes , which should never be interrupted: this is Delay, Event fetcher, interrupt handler, weak finalizer, idle process All those facilities should register themselves in UserInterruptHandler whenever they deciding to start or restart their process.
b) interrupt the first process, not found in (a), going from higher priority to lower. Then if you press the cmd-. multiple times, you will be able to interrupt anything which is not system-critical.
Because there is no reliable way to detect a processor hog process, unless you running CPU watcher and gather statistics on CPU consumption rates. Stopping a process which was running just before current one is like shooting in the clear sky in hope that duck will teleport right on the path of your bullet :)
-- Best regards, Igor Stasenko AKA sig.
Stéphane Ducasse wrote:
I like the idea. It provides a solution not depending on the scheduler strategy. We should implement it :)
Issue 4608: [ENH]: More robust user interrupt (http://code.google.com/p/pharo/issues/detail?id=4608) -- View this message in context: http://forum.world.st/Recursive-calls-hang-image-tp3728055p3728714.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Igor Stasenko wrote:
Well, it works for me, if i press it multiple times :)
Which VM? I pressed a bunch of times with Mac 4.2.5beta VM with no effect (OS X 10.7). -- View this message in context: http://forum.world.st/Recursive-calls-hang-image-tp3728055p3728753.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On 9 August 2011 03:18, Sean P. DeNigris <sean@clipperadams.com> wrote:
Igor Stasenko wrote:
Well, it works for me, if i press it multiple times :)
Which VM? I pressed a bunch of times with Mac 4.2.5beta VM with no effect (OS X 10.7).
Today i using only cog family VMs build on our servers. Because if i would use old ones, i will never know if things that we developing are working well.
-- View this message in context: http://forum.world.st/Recursive-calls-hang-image-tp3728055p3728753.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko AKA sig.
Igor Stasenko wrote:
Today i using only cog family VMs build on our servers. Because if i would use old ones, i will never know if things that we developing are working well.
Ahh, okay. It seems I'm now only waiting on OSProcess to be fixed before I switch too. -- View this message in context: http://forum.world.st/Recursive-calls-hang-image-tp3728055p3728788.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
On Mon, Aug 8, 2011 at 1:09 PM, Igor Stasenko <siguctua@gmail.com> wrote:
Hangs? Well it is normal, since it is busy evaluating an infinite recursion, right? :)
traditionally infinite recursion is caught by the low space notifier.
So, as far as i understand the problem is that you cannot interrupt it, by pressing Alt-. (or Cmd-. on macs)? Because there's little what could be done with code which goes into recursion, actually only one thing - fix it. :)
On 8 August 2011 21:47, Sean P. DeNigris <sean@clipperadams.com> wrote:
My image hung after executing: categoryName := $- asParser negate plus flatten, ($- asParser, #any asParser star flatten) optional star. categoryName parse: 'SuperMe'.
On the Moose list [1], Lukas pointed out the bug in my code which led to direct recursion, and that hanging under this circumstance was a bug in Pharo. Is this a known bug, or shall I file an issue?
[1] http://forum.world.st/PetitParser-crash-td3725129.html
-- View this message in context: http://forum.world.st/Recursive-calls-hang-image-tp3728055p3728055.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko AKA sig.
-- best, Eliot
On Mon, Aug 8, 2011 at 5:08 PM, Eliot Miranda <eliot.miranda@gmail.com>wrote:
On Mon, Aug 8, 2011 at 1:09 PM, Igor Stasenko <siguctua@gmail.com> wrote:
Hangs? Well it is normal, since it is busy evaluating an infinite recursion, right? :)
traditionally infinite recursion is caught by the low space notifier.
or to be blunt, if infinite recursion is /not/ caught by the low space notifier then the low space notifier is broken.
So, as far as i understand the problem is that you cannot interrupt it, by pressing Alt-. (or Cmd-. on macs)? Because there's little what could be done with code which goes into recursion, actually only one thing - fix it. :)
On 8 August 2011 21:47, Sean P. DeNigris <sean@clipperadams.com> wrote:
My image hung after executing: categoryName := $- asParser negate plus flatten, ($- asParser, #any asParser star flatten) optional star. categoryName parse: 'SuperMe'.
On the Moose list [1], Lukas pointed out the bug in my code which led to direct recursion, and that hanging under this circumstance was a bug in Pharo. Is this a known bug, or shall I file an issue?
[1] http://forum.world.st/PetitParser-crash-td3725129.html
-- View this message in context: http://forum.world.st/Recursive-calls-hang-image-tp3728055p3728055.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
-- Best regards, Igor Stasenko AKA sig.
-- best, Eliot
-- best, Eliot
participants (4)
-
Eliot Miranda -
Igor Stasenko -
Sean P. DeNigris -
Stéphane Ducasse