endless loop again

the mooc is a mine for Pharo bugs...


In the video at 6:12, we have a new method sending the new message. I've
made similar mistakes and Pharo does lock up, but then the operating
system (Windows 10) kills the Pharo VM. (Or perhaps there's a bug in
Pharo itself which just crashes the whole VM. I can't tell the difference.)
Is that because it's a memory leak? Does the VM have a fixed amount of
memory available, or can it request more from the OS?
Is there a way to recover from this error without killing the whole VM?
Most GUI systems I've used have at least two threads so that pushing a
button doesn't lock up the whole UI if the task takes a while. Does
Pharo always lock up for long-running tasks, or does it have some kind
of threading ability too? If a background thread gets in an infinite
loop, how do you kill it without killing the whole VM?


here was my answer

The real answer is a bit more complex so I may write some
approximations: - what you did a really tight loops that fills up the
memory really fast. - depending on the OS the VM can or not (in its
current state) allocate more. In some versions it has to preallocate.
"Most GUI systems I've used have at least two threads so that pushing a
button doesn't lock up the whole UI if the task takes a while. Does
Pharo always lock up for long-running tasks, or does it have some kind
of threading ability too? If a background thread gets in an infinite
loop, how do you kill it without killing the whole VM?"
Pharo has a full model for concurrent programming. Check the class
Process, Semaphore. We have some stress tests that create thousands of
threads without problems. You have also package such TaskIt to schedule
tasks
Now the actual problem that you see and that I would love to see fix in
the future is that the code you execute is run in the UI thread
(arghhhhh) It is still like that for historical reason. We should do one
pass on that but this is not that simple because it will raise a couple
of bugs.


Now I think that it would be great if people from the pharo core would
browse in diagonal the problems that students

encounter because there are our real customers and they show many
problems of the system. Especially the ones we do not see anymore.

Regarding the first part of your email, about UI lockups, it is almost
unavoidable, because in Pharo almost everything happens in the main
thread, as you pointed out. When only UI events should happen there,
and have background processes/async tasks for computation and I/O that
updates the UI by means of some sort of message channel between the
process and the UI.

This isn't a "feature" of Pharo only, other Smalltalks[1] have the
same "design" (or lack thereof) regarding what it is done in the main/UI thread.

I can't imagine a plan for changing that in the current tools, I think
it would require a major overhaul.

OTOH newer tools like Spotter seems to use background threads to do
its stuff, so the shift might have already begun.

Regards,

Esteban A. Maringolo

[1] VisualAge came with an separate OS process that could halt the vm
at a very low level when it was stuck in a tight loop. ST/X has a
process/message queue per os window, which allows you to kill one
window without taking down the whole image/vm.

2016-06-03 2:56 GMT-03:00 stepharo <[hidden email]>:

Le 3/6/16 à 19:16, Esteban A. Maringolo a écrit :
> Regarding the first part of your email, about UI lockups, it is almost
> unavoidable, because in Pharo almost everything happens in the main
> thread, as you pointed out.
Yes. This is all my point.

> When only UI events should happen there,
> and have background processes/async tasks for computation and I/O that
> updates the UI by means of some sort of message channel between the
> process and the UI.
>
> This isn't a "feature" of Pharo only, other Smalltalks[1] have the
> same "design" (or lack thereof) regarding what it is done in the main/UI thread.
:)
>
> I can't imagine a plan for changing that in the current tools, I think
> it would require a major overhaul.
I would like to see this point addressed. It would be good to have
less addition in Pharo before such point gets addressed.
Yes in VW it is the same.

> On 04 Jun 2016, at 9:13 , stepharo <[hidden email]> wrote:
>
>
>
> Le 3/6/16 à 19:16, Esteban A. Maringolo a écrit :
>> Regarding the first part of your email, about UI lockups, it is almost
>> unavoidable, because in Pharo almost everything happens in the main
>> thread, as you pointed out.
> Yes. This is all my point.

IMHO, all Pharo beginner tutorials should start by showing off Cmd - dot (or Alt - dot, on Win / Linux).

Not just because it's cool, but because it's necessary :)

Cheers,
Henry

Very true.

Yet, and I have already mentioned this years ago, it is technically totally possible to properly detect massive stack growth, before things get out of control. Sadly, VM people think this is not needed (or too costly).

Consider the following in Common Lisp (LispWorks):

CL-USER 1 > (defun fac (n) (if (< n 2) 1 (* n (fac (1- n)))))
FAC

CL-USER 2 > (fac 5)
120

CL-USER 3 > (fac 100)
93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000

CL-USER 4 > (fac 400)

Stack overflow (stack size 31744).
  1 (continue) Extend stack by 50%.
  2 (abort) Return to level 0.
  3 Return to top loop level 0.

Type :b for backtrace or :c <option number> to proceed.
Type :bug-form "<subject>" for a bug report template or :? for other options.

CL-USER 5 : 1 > :c 1

Stack overflow (stack size 48128).
  1 (continue) Extend stack by 50%.
  2 (abort) Return to level 0.
  3 Return to top loop level 0.

Type :b for backtrace or :c <option number> to proceed.
Type :bug-form "<subject>" for a bug report template or :? for other options.

CL-USER 6 : 1 > :c 1
64034522846623895262347970319503005850702583026002959458684445942802397169186831436278478647463264676294350575035856810848298162883517435228961988646802997937341654150838162426461942352307046244325015114448670890662773914918117331955996440709549671345290477020322434911210797593280795101545372667251627877890009349763765710326350331533965349868386831339352024373788157786791506311858702618270169819740062983025308591298346162272304558339520759611505302236086810433297255194852674432232438669948422404232599805551610635942376961399231917134063858996537970147827206606320217379472010321356624613809077942304597360699567595836096158715129913822286578579549361617654480453222007825818400848436415591229454275384803558374518022675900061399560145595206127211192918105032491008000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

CL-USER 7 > (defun infinite () (cons 'a (infinite)))
INFINIT

CL-USER 8 > (infinite)

Stack overflow (stack size 80896).
  1 (continue) Extend stack by 50%.
  2 (abort) Return to level 0.
  3 Return to top loop level 0.

Type :b for backtrace or :c <option number> to proceed.
Type :bug-form "<subject>" for a bug report template or :? for other options.

CL-USER 9 : 1 > :a

CL-USER 10 >

Just having an upper limit to the stack catches 99% of infinite loops - that would be nice to have.

This has existed for 10s of years AFAIK.

Sven

PS: Of course, the stack size can be set larger to begin with, if necessary. I believe it is even per execution thread.

IMHO, all Pharo beginner tutorials should start by showing off Cmd - dot (or Alt - dot, on Win / Linux). Not just because it's cool, but because it's necessary :) Cheers, Henry

Very true. Yet, and I have already mentioned this years ago, it is technically totally possible to properly detect massive stack growth, before things get out of control. Sadly, VM people think this is not needed (or too costly).

I was talking about our VM. It is good to know that it already exists in other Smalltalk implementations. You mean Smalltalk/X ?

> And, it could be done with virtually no costs at all - hardware check for this anyway.

Good to know ! There is hope then ;-)

> Jan
>
>

On Wed, Jun 08, 2016 at 11:11:13AM +0200, Sven Van Caekenberghe wrote:
Hi Sven,

I think that I remember this topic being discussed from time to time, but
I cannot recall specifics. Do you have a pointer to any discussions on the
mailing lists? I'm sure that there would be interest in doing this if it
can be done in an efficent manner.

Thanks,
Dave

2016-06-08 6:29 GMT-03:00 Sven Van Caekenberghe <[hidden email]>:
>
>> On 08 Jun 2016, at 11:24, Jan Vrany <[hidden email]> wrote:
>> Not entirely true :-) There are smalltalks out there that detect such stack growth and do the same as CL,
>> throw a (resumable) exception. Super-handy. Some of them have this for at least 10 years now :-)
>
> I was talking about our VM. It is good to know that it already exists in other Smalltalk implementations. You mean Smalltalk/X ?

Dolphin has this feature (see atached file), and AFAIR VisualAge too.
I implemented an infinite recursion, which was handled by Dolphin, but
crashed Pharo.


Regards,

May be you should raise the question in the vm mailing-list.

It would be a really great feature.

Stef


Le 8/6/16 à 21:33, Esteban A. Maringolo a écrit :