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.

In looking for REPL (it's in the Cuis base as Transcripter > readEvalPrint) I found a new way to get a hang-up. In a workspace do:

(Transcripter newInFrame: (0@0 extent: 100@200))
    nextPutAll: 'Hello there'; endEntry;
    newLine; print: 355.0/113; endEntry;
    readEvalPrint.

...and the clock stops. 'top' reports 100 %CPU for squeak.

 

On 06/02/2017 01:17 p.m., Bert Freudenberg wrote:

On Sat, Feb 4, 2017 at 7:09 PM, Dan Norton <[hidden email]> wrote:

 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.

Freezes on cog_macos64x64_squeak.cog.spur_201702021058 too. Maybe try the 64 bit windows VM?

- Bert -

 

Yes, we'd try that. I'm out of town, and will not be able to do it this week.

If anyone wants to try, when I tried Spur64 in Windows the image would crash. The workaround is to clear the World background (an ivar in WorldState). There seems to be some problem with jpeg decompression on that VM.

Thanks,

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

2017-02-07 1:42 GMT+01:00 Juan Vuletich <[hidden email]>:

 

On 06/02/2017 01:17 p.m., Bert Freudenberg wrote:

On Sat, Feb 4, 2017 at 7:09 PM, Dan Norton <[hidden email]> wrote:

 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.

Freezes on cog_macos64x64_squeak.cog.spur_201702021058 too. Maybe try the 64 bit windows VM?

- Bert -

 

Yes, we'd try that. I'm out of town, and will not be able to do it this week.

If anyone wants to try, when I tried Spur64 in Windows the image would crash. The workaround is to clear the World background (an ivar in WorldState). There seems to be some problem with jpeg decompression on that VM.

Thanks,

Yes, jpeg is broken in Win64, but works fine in MacOSX 64 and Linux 64 with same sources.

I bet that it's related to LLP64...

I tired to update to latest available code for this jpeg library, but it does not fix anything (and would introduce controversial deviations to the standard).

We could comment out the generation of jpeg plugin in the interim

 

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

 

I finally understood what was happening. The problem with is primitive 136:

primSignal: aSemaphore atMilliseconds: aSmallInteger
    "Signal the semaphore when the millisecond clock reaches the value of the second argument. Fail if the first argument is neither a Semaphore nor nil. Essential. See Object documentation whatIsAPrimitive."
    <primitive: 136>
    ^self primitiveFailed

If the requested tick is already in the past, all the VMs except for Spur-64 will signal the semaphore anyway. Spur-64 won't. Taking care of this in the Cuis image was easy enough.

Squeak seems not to be affected because it uses a newer primitive, that takes the large integer microsecond ticker, that might have the older behavior (signaling anyway). I'm not really sure, and maybe someone could check the primitive behavior and the corresponding assumptions in Squeak.

Older Squeak images are not affected, as they are all 32-bit. So maybe there's no action required. In any case, making the behavior consistent across VMs and in both primitives would be nice.

Cheers,

On 3/3/2017 3:55 PM, Juan Vuletich wrote:

Hi Folks,

Today, I was able to get closer to the origin of the problem. The problem is when Morphic tries to do a Delay (inter-cycle-pause) of 1 or two milliseconds. (Usually they are quite larger, and the problem does not appear). With the 64-bit VM, sometimes very short delays hang the complete system. I don't know why, but this:

waitDelay _ Delay forMilliseconds: 50.
[ true ] whileTrue: [
    1000 atRandom print.
    waitDelay setDelay: 1; wait ].

is enough to hang Cuis in a short time. When trying to reproduce the problem in Squeak I had mixed results. It doesn't seem to hang there, but if I let this run for a couple of minutes and then try to halt with alt-. , then the hang occurs, and Squeak becomes irresponsibe. As a workaround, in Cuis in the inter cycle pause, I'm avoiding very short delays.

I'm not sure if the bug is in the VM, in  the image, or both, but it is still there, and it also affects Squeak. I haven't tried it, but Pharo might also have the problem (if not, it can show a possible solution).

BTW, Bert, I guess Squeak never does short delays in #interCyclePause: ...

Thanks,

On 2/6/2017 12:28 PM, Bert Freudenberg wrote:

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 -

 

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

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

In the VM, the millisecond clock wraps within the 32 bit integer range:

  #define MillisecondClockMask 0x1FFFFFFF

In the Cuis image, Delay class>>handleTimerEvent does this:

  nextTick := nextTick min: SmallInteger maxVal.

On a 64-bit Spur image, SmallInteger maxVal is 16rFFFFFFFFFFFFFFF, but on
a 32-bit image it is 16r3FFFFFFF.

Could that be it?

I don't really know how to test in Squeak. As you say, Squeak is now
using the microsecond clock in #handleTimerEvent. I do not see anything
in primitiveSignalAtMilliseconds that would behave any differently on
a 64 bit versus 32 bit image or VM, but I do not know how to test to
be sure.

Dave


On Mon, Mar 06, 2017 at 11:06:22AM -0300, Juan Vuletich wrote:
>
> I finally understood what was happening. The problem with is primitive 136:
>
> primSignal: aSemaphore atMilliseconds: aSmallInteger
>     "Signal the semaphore when the millisecond clock reaches the value
> of the second argument. Fail if the first argument is neither a
> Semaphore nor nil. Essential. See Object documentation whatIsAPrimitive."
> <primitive: 136>
>     ^self primitiveFailed
>
> If the requested tick is already in the past, all the VMs except for
> Spur-64 will signal the semaphore anyway. Spur-64 won't. Taking care of
> this in the Cuis image was easy enough.
>
> Squeak seems not to be affected because it uses a newer primitive, that
> takes the large integer microsecond ticker, that might have the older
> behavior (signaling anyway). I'm not really sure, and maybe someone
> could check the primitive behavior and the corresponding assumptions in
> Squeak.
>
> Older Squeak images are not affected, as they are all 32-bit. So maybe
> there's no action required. In any case, making the behavior consistent
> across VMs and in both primitives would be nice.
>
> Cheers,
>
> On 3/3/2017 3:55 PM, Juan Vuletich wrote:
> >
> >
> >
> >Hi Folks,
> >
> >Today, I was able to get closer to the origin of the problem. The
> >problem is when Morphic tries to do a Delay (inter-cycle-pause) of 1
> >or two milliseconds. (Usually they are quite larger, and the problem
> >does not appear). With the 64-bit VM, sometimes very short delays hang
> >the complete system. I don't know why, but this:
> >
> >waitDelay _ Delay forMilliseconds: 50.
> >[ true ] whileTrue: [
> >    1000 atRandom print.
> >    waitDelay setDelay: 1; wait ].
> >
> >is enough to hang Cuis in a short time. When trying to reproduce the
> >problem in Squeak I had mixed results. It doesn't seem to hang there,
> >but if I let this run for a couple of minutes and then try to halt
> >with alt-. , then the hang occurs, and Squeak becomes irresponsibe. As
> >a workaround, in Cuis in the inter cycle pause, I'm avoiding very
> >short delays.
> >
> >I'm not sure if the bug is in the VM, in  the image, or both, but it
> >is still there, and it also affects Squeak. I haven't tried it, but
> >Pharo might also have the problem (if not, it can show a possible
> >solution).
> >
> >BTW, Bert, I guess Squeak never does short delays in #interCyclePause: ...
> >
> >Thanks,
> >
> >On 2/6/2017 12:28 PM, Bert Freudenberg wrote:
> >>
> >>
> >>
> >>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]
> >><mailto:[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 <https://www.zoho.com/mail/>
> >>
> >>
> >>        ---- On Mon, 06 Feb 2017 09:19:48 -0300 *[hidden email]
> >>        <mailto:[hidden email]> * wrote ----
> >>
> >>        On Mon, Feb 6, 2017 at 3:15 AM, David T. Lewis
> >>        <[hidden email] <mailto:[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 -
> >>
> >>
> >>
> >
> >
> >--
> >Juan Vuletich
> >www.cuis-smalltalk.org
> >https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
> >@JuanVuletich
>
>
> --
> Juan Vuletich
> www.cuis-smalltalk.org
> https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
> @JuanVuletich
>

On Thu, Mar 09, 2017 at 12:41:44PM -0800, Eliot Miranda wrote:
>
> Hi David,
>
> On Mon, Mar 6, 2017 at 5:50 PM, David T. Lewis <[hidden email]> wrote:
>
> >
> > In the VM, the millisecond clock wraps within the 32 bit integer range:
> >
> >   #define MillisecondClockMask 0x1FFFFFFF
> >
> > In the Cuis image, Delay class>>handleTimerEvent does this:
> >
> >   nextTick := nextTick min: SmallInteger maxVal.
> >
> > On a 64-bit Spur image, SmallInteger maxVal is 16rFFFFFFFFFFFFFFF, but on
> > a 32-bit image it is 16r3FFFFFFF.
> >
> > Could that be it?
> >
> > I don't really know how to test in Squeak. As you say, Squeak is now
> > using the microsecond clock in #handleTimerEvent. I do not see anything
> > in primitiveSignalAtMilliseconds that would behave any differently on
> > a 64 bit versus 32 bit image or VM, but I do not know how to test to
> > be sure.
> >
>
> I bet that the following code from primitiveSignalAtMilliseconds ends up
> wrapping when given
>     Delay primSignal: s atMilliseconds: Time primMillisecondClock - 10.
>
> deltaMsecs := msecs - (self ioMSecs bitAnd: MillisecondClockMask).
> deltaMsecs < 0 ifTrue:
> [deltaMsecs := deltaMsecs + MillisecondClockMask + 1].
> nextWakeupUsecs := self ioUTCMicroseconds + (deltaMsecs * 1000).
>
> and I bet you'll find that the VM will wake up in about 6 days and 5 hours
> ;-)
>

No. The failure is specific to the 64 bit VM. Source code for the primitive
is the same in either case.

>
> I suppose we could fix this, but I'm *much* happier to simply not use
> primitiveSignalAtMilliseconds and stay with the simpler and wrapping-immune
> primitiveSignalAtUTCMicroseconds

Fair enough, but given that there is a demonstrated bug that affects only
the 64-bit VM, and given that it expresses itself intermittently and in ways
that affect only someone who is attempting to migrate their existing V3 image
to Spur, then I would say that it makes very good sense to take the time
to fix it if we are able to do so. After all, there may be other people who
will want to migrate V3 images to Spur, and there is no point in making the
process needlessly difficult.

I do not have the solution, but maybe someone else can help. So I am asking
for help here. Can someone with a working 64-bit build environment please
check and see if what I said in an earlier email might make a difference:

  I see that ioMSecs() is declared as signed long (32 bits), but it is used
  in expression with a 64 bit usqInt. So maybe it needs a cast, or maybe
  the variables like msecs and deltaMsecs in primitiveSignalAtMilliseconds
  should be declared as 32 bit long and unsigned long to match the actual usage.

Thanks,

Dave