Squeak VM - Freeze after Morph Activity

Freeze after Morph Activity

Classic

List

Threaded

68 messages Options

1234

Dan Norton

Re: Freeze after Morph Activity

On 01/29/2017 08:33 PM, Dan Norton wrote:

> The plot thickens, without clarity...
>
> On two occasions when the freeze occurred, things locked up to the
> extent that the system pointer in Debian could not be moved. Some
> keyboard events were accepted:
>
>
> ctl-esc followed by arrow keys
>
> alt-space followed by arrow keys

The system pointer problem was due to a defective mouse. Unfortunately
replacing it did not solve the freeze. After a freeze, I find that pkill
will cause output to crash.dmp and the latest is attached.

- Dan

afterFreeze.bz2 (2K) Download Attachment

Bert Freudenberg

Re: Freeze after Morph Activity

On Mon, Jan 30, 2017 at 5:48 PM, Dan Norton <[hidden email]> wrote:

After a freeze, I find that pkill will cause output to crash.dmp and the latest is attached.

That looks benign.

How about attaching strace when frozen?

sudo strace -p <pid>

This should log all system calls the VM is still doing. Then press alt-. and see if the VM processes that.

And if all else fails, you may have to whip out gdb to see what exactly is going on.

- Bert -

Dan Norton

Re: Freeze after Morph Activity

On 01/30/2017 11:58 AM, Bert Freudenberg wrote:

 
On Mon, Jan 30, 2017 at 5:48 PM, Dan Norton <[hidden email]> wrote:

After a freeze, I find that pkill will cause output to crash.dmp and the latest is attached.

That looks benign.

How about attaching strace when frozen?

sudo strace -p <pid>

This should log all system calls the VM is still doing. Then press alt-. and see if the VM processes that.

# strace -p 2475

produces lots of...
nanosleep({0, 0}, 0x7fff9b9b6060)       = 0
select(4, [3], [], [3], {0, 0})         = 0 (Timeout)
recvmsg(3, 0x7fff9b9b5df0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], [], [3], {0, 0})         = 0 (Timeout)
nanosleep({0, 0}, 0x7fff9b9b6060)       = 0
select(4, [3], [], [3], {0, 0})         = 0 (Timeout)
recvmsg(3, 0x7fff9b9b5df0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], [], [3], {0, 0})         = 0 (Timeout)
^Cnanosleep({0, 0}, Process 2475 detached
<detached ...>

... before my packages are loaded as well as after the freeze. Identical AFAICT.
alt-. is not processed after the freeze.

- Dan

Dan Norton

Re: Freeze after Morph Activity

When a freeze occurs, it's usually(tm) during an animation, probably because the movement of an ellipse is done in small increments of 92 per hop. This is within a block like so:

self when: #morphicStep evaluate: [ :delta | <movement> ].

self startSteppingStepTime: step.

How can the breakpoint be set in this block for gdb? We need source for some C module.

- Dan

On 01/30/2017 02:58 PM, Dan Norton wrote:

On 01/30/2017 11:58 AM, Bert Freudenberg wrote:
 
On Mon, Jan 30, 2017 at 5:48 PM, Dan Norton <[hidden email]> wrote:

After a freeze, I find that pkill will cause output to crash.dmp and the latest is attached.

That looks benign.

How about attaching strace when frozen?

sudo strace -p <pid>

This should log all system calls the VM is still doing. Then press alt-. and see if the VM processes that.
# strace -p 2475

produces lots of...
nanosleep({0, 0}, 0x7fff9b9b6060)       = 0
select(4, [3], [], [3], {0, 0})         = 0 (Timeout)
recvmsg(3, 0x7fff9b9b5df0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], [], [3], {0, 0})         = 0 (Timeout)
nanosleep({0, 0}, 0x7fff9b9b6060)       = 0
select(4, [3], [], [3], {0, 0})         = 0 (Timeout)
recvmsg(3, 0x7fff9b9b5df0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], [], [3], {0, 0})         = 0 (Timeout)
^Cnanosleep({0, 0}, Process 2475 detached
<detached ...>

... before my packages are loaded as well as after the freeze. Identical AFAICT.
alt-. is not processed after the freeze.

- Dan

Bert Freudenberg

Re: Freeze after Morph Activity

In reply to this post by Dan Norton

On Mon, Jan 30, 2017 at 8:58 PM, Dan Norton <[hidden email]> wrote:

# strace -p 2475

produces lots of...
nanosleep({0, 0}, 0x7fff9b9b6060)       = 0
select(4, [3], [], [3], {0, 0})         = 0 (Timeout)
recvmsg(3, 0x7fff9b9b5df0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], [], [3], {0, 0})         = 0 (Timeout)
nanosleep({0, 0}, 0x7fff9b9b6060)       = 0
select(4, [3], [], [3], {0, 0})         = 0 (Timeout)
recvmsg(3, 0x7fff9b9b5df0, 0)           = -1 EAGAIN (Resource temporarily unavailable)
select(4, [3], [], [3], {0, 0})         = 0 (Timeout)
^Cnanosleep({0, 0}, Process 2475 detached
<detached ...>

... before my packages are loaded as well as after the freeze. Identical AFAICT.
alt-. is not processed after the freeze.

Normally I'd expect the VM to do a read() call after pressing a key. The select() call is to see if something is available, and if so, it should be received. Not sure why it's calling recvmsg() even though select() timed out ... Is this the normal behavior? I don't have Linux running to check.

When not frozen, pressing a key should result in recvmsg() retrieving that key event.

- Bert -

Bert Freudenberg

Re: Freeze after Morph Activity

In reply to this post by Dan Norton

On Mon, Jan 30, 2017 at 9:43 PM, Dan Norton <[hidden email]> wrote:

When a freeze occurs, it's usually(tm) during an animation, probably because the movement of an ellipse is done in small increments of 92 per hop. This is within a block like so:

self when: #morphicStep evaluate: [ :delta | <movement> ].

self startSteppingStepTime: step.

How can the breakpoint be set in this block for gdb? We need source for some C module.

With gdb you can't debug at the Smalltalk level (that's what alt-. is for). You can only attach to the process, break into it and figure out what's going on. Which may be very hard. Also, you may have to compile your own VM with debug info (or do we have pre-built ones somewhrere?)

- Bert -

Dan Norton

Re: Freeze after Morph Activity

Attached is a few lines of code which can reproduce the problem. File it in then do:

Tokenish start

in a Cuis workspace. You may have to let it run for a while, the time to failure is not predictable. Starting multiples of them may bring the freeze sooner.

- Dan

On 01/30/2017 04:23 PM, Bert Freudenberg wrote:

 
On Mon, Jan 30, 2017 at 9:43 PM, Dan Norton <[hidden email]> wrote:

When a freeze occurs, it's usually(tm) during an animation, probably because the movement of an ellipse is done in small increments of 92 per hop. This is within a block like so:

self when: #morphicStep evaluate: [ :delta | <movement> ].

self startSteppingStepTime: step.

How can the breakpoint be set in this block for gdb? We need source for some C module.

With gdb you can't debug at the Smalltalk level (that's what alt-. is for). You can only attach to the process, break into it and figure out what's going on. Which may be very hard. Also, you may have to compile your own VM with debug info (or do we have pre-built ones somewhrere?)

- Bert -

Tokenish.st (2K) Download Attachment

Dan Norton

Re: Freeze after Morph Activity

Hi Folks,

On Debian8, using cog_linux64x64_squeak.cog.spur_201702021058 and Cuis5.0-3040-spur-64 updated to 3043, everything will stop, including the clock in the Cuis task bar. Neither mouse nor keyboard events are processed. Trying to interrupt with alt-. is unsuccessful. CogSpur was re-cloned and the test case was re-run with the same result.

On Windows 10, using cog_win32x86_squeak.cog.spur_201702021058, and Cuis 5.0 3043, the same test case runs for hours with no problem.

Before the freeze, %CPU as reported by 'top' is about 4.

When the freeze occurs, %CPU as reported by 'top' rises to 11.3 which reminds me of a loop.

Why would the problem show up on Debian8 but not Win10?

- Dan

On 01/30/2017 08:35 PM, Dan Norton wrote:

Attached is a few lines of code which can reproduce the problem. File it in then do:

Tokenish start

in a Cuis workspace. You may have to let it run for a while, the time to failure is not predictable. Starting multiples of them may bring the freeze sooner.

- Dan

On 01/30/2017 04:23 PM, Bert Freudenberg wrote:
 
On Mon, Jan 30, 2017 at 9:43 PM, Dan Norton <[hidden email]> wrote:

When a freeze occurs, it's usually(tm) during an animation, probably because the movement of an ellipse is done in small increments of 92 per hop. This is within a block like so:

self when: #morphicStep evaluate: [ :delta | <movement> ].

self startSteppingStepTime: step.

How can the breakpoint be set in this block for gdb? We need source for some C module.

With gdb you can't debug at the Smalltalk level (that's what alt-. is for). You can only attach to the process, break into it and figure out what's going on. Which may be very hard. Also, you may have to compile your own VM with debug info (or do we have pre-built ones somewhrere?)

- Bert -

Juan Vuletich-3

We need help from VM experts. Re: Freeze after Morph Activity

In reply to this post by Dan Norton

Hi Folks,

It seems we found a problem in Spur-64 on Linux. Eliot & VM developers and experts, please, we need your help.

Cuis users have been experiencing this problem since we started using Spur-64. At random times, the image just stops working. No Smalltalk process is run, and the VM needs to be killed from the OS.

In my experience, most of the time it takes several hours for the problem to happen. Dan found a simple way to make it happen rather quickly. No FFI is involved, just pretty basic Smalltalk. I can confirm that the problem does not happen using Spur-32 on the same platform.

Thanks,

On 30/01/2017 10:35 p.m., Dan Norton wrote:

Attached is a few lines of code which can reproduce the problem. File it in then do:

Tokenish start

in a Cuis workspace. You may have to let it run for a while, the time to failure is not predictable. Starting multiples of them may bring the freeze sooner.

- Dan

On 01/30/2017 04:23 PM, Bert Freudenberg wrote:
 
On Mon, Jan 30, 2017 at 9:43 PM, Dan Norton <[hidden email]> wrote:

When a freeze occurs, it's usually(tm) during an animation, probably because the movement of an ellipse is done in small increments of 92 per hop. This is within a block like so:

self when: #morphicStep evaluate: [ :delta | <movement> ].

self startSteppingStepTime: step.

How can the breakpoint be set in this block for gdb? We need source for some C module.

With gdb you can't debug at the Smalltalk level (that's what alt-. is for). You can only attach to the process, break into it and figure out what's going on. Which may be very hard. Also, you may have to compile your own VM with debug info (or do we have pre-built ones somewhrere?)

- Bert -

-- 
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
@JuanVuletich

David T. Lewis

Re: We need help from VM experts. Re: Freeze after Morph Activity

On Sun, Feb 05, 2017 at 04:09:39PM -0300, Juan Vuletich wrote:

>
> Hi Folks,
>
> It seems we found a problem in Spur-64 on Linux. Eliot & VM developers
> and experts, please, we need your help.
>
> Cuis users have been experiencing this problem since we started using
> Spur-64. At random times, the image just stops working. No Smalltalk
> process is run, and the VM needs to be killed from the OS.
>
> In my experience, most of the time it takes several hours for the
> problem to happen. Dan found a simple way to make it happen rather
> quickly. No FFI is involved, just pretty basic Smalltalk. I can confirm
> that the problem does not happen using Spur-32 on the same platform.
>

I can confirm this on my Ubuntu laptop running Cuis5.0-3040-spur-64.image.

I filed in the Tokenish.st demo, and started several Tokenish morphs that
bounced along cheerfully until the image hung up.

The VM is still running and using CPU. Top shows about 5% CPU, which several
times greater than for an idle image, but certainly not abnormally high.

The actual VM process shows a "waiting" state in /proc/<pid>/status, which
is exactly like what I would expect for a normal running VM. Here is a sample
of what I see for the hung image/VM:

lewis@lewis-Gazelle-Pro:/proc/32609$ cat /proc/32609/status
Name: squeak
State: S (sleeping)
Tgid: 32609
Ngid: 0
Pid: 32609
PPid: 2779
TracerPid: 0
Uid: 1000 1000 1000 1000
Gid: 1000 1000 1000 1000
FDSize: 256
Groups: 4 24 27 30 46 115 131 1000
VmPeak: 147456 kB
VmSize: 131156 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 40468 kB
VmRSS: 40464 kB
VmData: 57496 kB
VmStk: 1740 kB
VmExe: 1304 kB
VmLib: 5916 kB
VmPTE: 240 kB
VmSwap: 0 kB
Threads: 2
SigQ: 0/31381
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000001000
SigCgt: 0000000190000648
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000003fffffffff
Seccomp: 0
Cpus_allowed: ff
Cpus_allowed_list: 0-7
Mems_allowed: 00000000,00000001
Mems_allowed_list: 0
voluntary_ctxt_switches: 14946247
nonvoluntary_ctxt_switches: 2443
lewis@lewis-Gazelle-Pro:/proc/32609$

The VM that I am using is:

Virtual Machine
---------------
/usr/local/lib/squeak/5.0-201608171728-64/squeak
Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-cb.1919]
Unix built on Sep 25 2016 15:59:10 Compiler: 4.6.3
platform sources revision VM: 201608171728 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Wed Aug 17 10:28:01 2016 -0700 $ Plugins: 201608171728 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
CoInterpreter VMMaker.oscog-cb.1919 uuid: 00a8dd2a-bc8d-4552-b400-be781c8aabec Sep 25 2016
StackToRegisterMappingCogit VMMaker.oscog-cb.1919 uuid: 00a8dd2a-bc8d-4552-b400-be781c8aabec Sep 25 2016

I cannot see what is wrong, but maybe this will prompt some ideas.

Dave

Dan Norton

Re: We need help from VM experts. Re: Freeze after Morph Activity

When the hang-up occurs, a #morphicStep is involved. I've never seen it
otherwise.

Attached is what may be the minimal test case: an empty step loop. File
in the attachment and in a workspace do:

Minish start

- Dan

On 02/05/2017 03:42 PM, David T. Lewis wrote:

>
> On Sun, Feb 05, 2017 at 04:09:39PM -0300, Juan Vuletich wrote:
>>
>> Hi Folks,
>>
>> It seems we found a problem in Spur-64 on Linux. Eliot & VM developers
>> and experts, please, we need your help.
>>
>> Cuis users have been experiencing this problem since we started using
>> Spur-64. At random times, the image just stops working. No Smalltalk
>> process is run, and the VM needs to be killed from the OS.
>>
>> In my experience, most of the time it takes several hours for the
>> problem to happen. Dan found a simple way to make it happen rather
>> quickly. No FFI is involved, just pretty basic Smalltalk. I can confirm
>> that the problem does not happen using Spur-32 on the same platform.
>>
>
> I can confirm this on my Ubuntu laptop running Cuis5.0-3040-spur-64.image.
>
> I filed in the Tokenish.st demo, and started several Tokenish morphs that
> bounced along cheerfully until the image hung up.
>
> The VM is still running and using CPU. Top shows about 5% CPU, which several
> times greater than for an idle image, but certainly not abnormally high.
>
> The actual VM process shows a "waiting" state in /proc/<pid>/status, which
> is exactly like what I would expect for a normal running VM. Here is a sample
> of what I see for the hung image/VM:
>
> lewis@lewis-Gazelle-Pro:/proc/32609$ cat /proc/32609/status
> Name: squeak
> State: S (sleeping)
> Tgid: 32609
> Ngid: 0
> Pid: 32609
> PPid: 2779
> TracerPid: 0
> Uid: 1000 1000 1000 1000
> Gid: 1000 1000 1000 1000
> FDSize: 256
> Groups: 4 24 27 30 46 115 131 1000
> VmPeak: 147456 kB
> VmSize: 131156 kB
> VmLck: 0 kB
> VmPin: 0 kB
> VmHWM: 40468 kB
> VmRSS: 40464 kB
> VmData: 57496 kB
> VmStk: 1740 kB
> VmExe: 1304 kB
> VmLib: 5916 kB
> VmPTE: 240 kB
> VmSwap: 0 kB
> Threads: 2
> SigQ: 0/31381
> SigPnd: 0000000000000000
> ShdPnd: 0000000000000000
> SigBlk: 0000000000000000
> SigIgn: 0000000000001000
> SigCgt: 0000000190000648
> CapInh: 0000000000000000
> CapPrm: 0000000000000000
> CapEff: 0000000000000000
> CapBnd: 0000003fffffffff
> Seccomp: 0
> Cpus_allowed: ff
> Cpus_allowed_list: 0-7
> Mems_allowed: 00000000,00000001
> Mems_allowed_list: 0
> voluntary_ctxt_switches: 14946247
> nonvoluntary_ctxt_switches: 2443
> lewis@lewis-Gazelle-Pro:/proc/32609$
>
> The VM that I am using is:
>
> Virtual Machine
> ---------------
> /usr/local/lib/squeak/5.0-201608171728-64/squeak
> Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-cb.1919]
> Unix built on Sep 25 2016 15:59:10 Compiler: 4.6.3
> platform sources revision VM: 201608171728 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Wed Aug 17 10:28:01 2016 -0700 $ Plugins: 201608171728 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
> CoInterpreter VMMaker.oscog-cb.1919 uuid: 00a8dd2a-bc8d-4552-b400-be781c8aabec Sep 25 2016
> StackToRegisterMappingCogit VMMaker.oscog-cb.1919 uuid: 00a8dd2a-bc8d-4552-b400-be781c8aabec Sep 25 2016
>
>
> I cannot see what is wrong, but maybe this will prompt some ideas.
>
> Dave
>

Minish.st (1K) Download Attachment

Levente Uzonyi

Re: We need help from VM experts. Re: Freeze after Morph Activity

In reply to this post by Juan Vuletich-3

At this point, I would simply install a REPL and would try to connect
to the image after the morphic freeze to see what happened.
I'm still not convinced about this being a VM bug. It might as well be an
image side bug, which simply doesn't happen on windows due to VM
differences.

Levente

David T. Lewis

Re: We need help from VM experts. Re: Freeze after Morph Activity

In reply to this post by Dan Norton

On Sun, Feb 05, 2017 at 04:51:06PM -0500, Dan Norton wrote:

>
> When the hang-up occurs, a #morphicStep is involved. I've never seen it
> otherwise.
>
> Attached is what may be the minimal test case: an empty step loop. File
> in the attachment and in a workspace do:
>
> Minish start
>
> - Dan

So far I have not been able to reproduce the hangup with the Minish example.
I've have about 20 of them open for about a half hour or so. Maybe it's just
really intermittent.

Dave

David T. Lewis

Re: We need help from VM experts. Re: Freeze after Morph Activity

On Sun, Feb 05, 2017 at 08:34:02PM -0500, David T. Lewis wrote:

>
> On Sun, Feb 05, 2017 at 04:51:06PM -0500, Dan Norton wrote:
> >
> > When the hang-up occurs, a #morphicStep is involved. I've never seen it
> > otherwise.
> >
> > Attached is what may be the minimal test case: an empty step loop. File
> > in the attachment and in a workspace do:
> >
> > Minish start
> >
> > - Dan
>
>
> So far I have not been able to reproduce the hangup with the Minish example.
> I've have about 20 of them open for about a half hour or so. Maybe it's just
> really intermittent.
>

I ran for over an hour with the Minish morphs going, no problem. But I can
get the image to hang in less than a minute by opening a bunch of bouncing
Tokenish morphs.

It would be interesting to try reproducing this in a Squeak image, but I
have not quite figured out how to make the Tokenish example work in Squeak.
Maybe someone with more experience in Morphic can try it.

Levente's suggestion of starting up a REPL loop to retain access to the image
is a good idea too.

Dave

Dan Norton

Re: We need help from VM experts. Re: Freeze after Morph Activity

On 02/05/2017 09:15 PM, David T. Lewis wrote:

>
> On Sun, Feb 05, 2017 at 08:34:02PM -0500, David T. Lewis wrote:
>>
>> On Sun, Feb 05, 2017 at 04:51:06PM -0500, Dan Norton wrote:
>>>
>>> When the hang-up occurs, a #morphicStep is involved. I've never seen it
>>> otherwise.
>>>
>>> Attached is what may be the minimal test case: an empty step loop. File
>>> in the attachment and in a workspace do:
>>>
>>> Minish start
>>>
>>> - Dan
>>
>> So far I have not been able to reproduce the hangup with the Minish example.
>> I've have about 20 of them open for about a half hour or so. Maybe it's just
>> really intermittent.
>>
> I ran for over an hour with the Minish morphs going, no problem. But I can
> get the image to hang in less than a minute by opening a bunch of bouncing
> Tokenish morphs.

Hi Dave,

You called it right: really intermittent with Minish. The first time I
ran it, it hung in less than one minute - right after a print-it for
"Time now print24" which I added to the workspace. But after that, I ran
7 of them for hours with no hang.

Attached is a package of test cases I've been using to try to determine
what does and does not hang - starting with Tokenish and down to Minish,
each one taking something out of the loop. Maybe something in there
will be useful.

- Dan

Freeze.pck.st (8K) Download Attachment

Bert Freudenberg

Re: We need help from VM experts. Re: Freeze after Morph Activity

In reply to this post by David T. Lewis

On Mon, Feb 6, 2017 at 3:15 AM, David T. Lewis <[hidden email]> wrote:

It would be interesting to try reproducing this in a Squeak image, but I
have not quite figured out how to make the Tokenish example work in Squeak.

See attachment. Did not freeze on Mac with 10 Tokenish jumping.

- Bert -

TokenishSq.1.cs (2K) Download Attachment

Juan Vuletich-3

Re: We need help from VM experts. Re: Freeze after Morph& nbsp; & nbsp; & nbsp; & nbsp; Activity

Were you usig Spur64? On Debian it does not freeze with CogV3 or Spur32. Only with Spur64.

Thanks,
Juan

Sent using Zoho Mail

---- On Mon, 06 Feb 2017 09:19:48 -0300 [hidden email] wrote ----

On Mon, Feb 6, 2017 at 3:15 AM, David T. Lewis <[hidden email]> wrote:
It would be interesting to try reproducing this in a Squeak image, but I
have not quite figured out how to make the Tokenish example work in Squeak.

See attachment. Did not freeze on Mac with 10 Tokenish jumping.
- Bert -

David T. Lewis

Re: We need help from VM experts. Re: Freeze after Morph Activity

In reply to this post by Bert Freudenberg

On Mon, Feb 06, 2017 at 01:19:48PM +0100, Bert Freudenberg wrote:
>
> On Mon, Feb 6, 2017 at 3:15 AM, David T. Lewis <[hidden email]> wrote:
>
> > It would be interesting to try reproducing this in a Squeak image, but I
> > have not quite figured out how to make the Tokenish example work in Squeak.
> >
>
> See attachment. Did not freeze on Mac with 10 Tokenish jumping.
> - Bert -

I am running it now on Ubuntu 64-bit Spur Squeak, with the same VM that I
used with Cuis. I have been running a dozen Tokenish morphs for about an
hour, so far no freeze. The morphs are bouncing much more slowly on Squeak
than on Cuis, so I think that the test is loading Cuis much more heavily.

I cannot look further now, but I'll take another look in about 12 hours and
see if I can speed up the Squeak animation and possibly freeze the image.

Dave

Bert Freudenberg

Re: We need help from VM experts. Re: Freeze after Morph Activity

On Mon, Feb 6, 2017 at 3:11 PM, David T. Lewis <[hidden email]> wrote:

On Mon, Feb 06, 2017 at 01:19:48PM +0100, Bert Freudenberg wrote:
>
> On Mon, Feb 6, 2017 at 3:15 AM, David T. Lewis <[hidden email]> wrote:
>
> > It would be interesting to try reproducing this in a Squeak image, but I
> > have not quite figured out how to make the Tokenish example work in Squeak.
> >
>
> See attachment. Did not freeze on Mac with 10 Tokenish jumping.
> - Bert -

I am running it now on Ubuntu 64-bit Spur Squeak, with the same VM that I
used with Cuis. I have been running a dozen Tokenish morphs for about an
hour, so far no freeze. The morphs are bouncing much more slowly on Squeak
than on Cuis, so I think that the test is loading Cuis much more heavily.

I cannot look further now, but I'll take another look in about 12 hours and
see if I can speed up the Squeak animation and possibly freeze the image.

With a single Tokenish morph and enabling the higherPerformance preference, the animation speed looks pretty much the same in Squeak. But with multiple ones animating, perf goes way down in Squeak :(

- Bert -

Bert Freudenberg

Re: We need help from VM experts. Re: Freeze after Morph& nbsp; & nbsp; & nbsp; & nbsp; Activity

In reply to this post by Juan Vuletich-3

Yes, I tried with Spur64. Have not seen it freeze yet on Mac in Squeak, but we possibly have not replicated the test well enough yet.

It *did* freeze in Cuis Spur64 on Mac too.

- Bert -

On Mon, Feb 6, 2017 at 2:08 PM, Juan Vuletich <[hidden email]> wrote:

Were you usig Spur64? On Debian it does not freeze with CogV3 or Spur32. Only with Spur64.

Thanks,
Juan

Sent using Zoho Mail

---- On Mon, 06 Feb 2017 09:19:48 -0300 [hidden email] wrote ----

On Mon, Feb 6, 2017 at 3:15 AM, David T. Lewis <[hidden email]> wrote:
It would be interesting to try reproducing this in a Squeak image, but I
have not quite figured out how to make the Tokenish example work in Squeak.

See attachment. Did not freeze on Mac with 10 Tokenish jumping.
- Bert -

1234

Freeze after Morph Activity

Re: Freeze after Morph Activity

Re: Freeze after Morph Activity

Re: Freeze after Morph Activity

Re: Freeze after Morph Activity

Re: Freeze after Morph Activity

Re: Freeze after Morph Activity

Re: Freeze after Morph Activity

Re: Freeze after Morph Activity

We need help from VM experts. Re: Freeze after Morph Activity

Re: We need help from VM experts. Re: Freeze after Morph Activity

Re: We need help from VM experts. Re: Freeze after Morph Activity

Re: We need help from VM experts. Re: Freeze after Morph Activity

Re: We need help from VM experts. Re: Freeze after Morph Activity

Re: We need help from VM experts. Re: Freeze after Morph Activity

Re: We need help from VM experts. Re: Freeze after Morph Activity

Re: We need help from VM experts. Re: Freeze after Morph Activity

Re: We need help from VM experts. Re: Freeze after Morph&amp; nbsp; &amp; nbsp; &amp; nbsp; &amp; nbsp; Activity

Re: We need help from VM experts. Re: Freeze after Morph Activity

Re: We need help from VM experts. Re: Freeze after Morph Activity

Re: We need help from VM experts. Re: Freeze after Morph&amp; nbsp; &amp; nbsp; &amp; nbsp; &amp; nbsp; Activity

Re: We need help from VM experts. Re: Freeze after Morph& nbsp; & nbsp; & nbsp; & nbsp; Activity

Re: We need help from VM experts. Re: Freeze after Morph& nbsp; & nbsp; & nbsp; & nbsp; Activity