Morphic or forking bug?

I have a puzzling bug. I've narrowed the scenario down to this code:

Cranky»initA
   a := ((StringMorph contents: '####') color: Color white) position: (0@0).
   m addMorph: a

Cranky»initialize
   f := Form fromFileNamed: 'hot_air_balloon_mysticmorning.jpg'.
   m := ImageMorph new.
   m form: f.
   self initA.
   m openInWindowLabeled: 'Cranky'.
   delay := (Delay forSeconds: 5).
   [ [ true ] whileTrue: [ a contents: 0 asString. delay wait ] fork

I can run this application for hours and hours with no problem. However, if I run it for a while and then close the application and then save/exit the image, the next time I start the image, there is some likelihood it will crash dump. The probability is something like 5-10%.

Interestingly, if I remove the statement...

a contents: 0 asString.

from the infinite loop, I've not been able to replicate the crash. Is there something wrong with the way I'm updating the contents of the StringMorph?

Oh, I forgot to mention, the crash dump says I got a segmentation fault.

horrido wrote

I have a puzzling bug. I've narrowed the scenario down to this code:

Cranky»initA
   a := ((StringMorph contents: '####') color: Color white) position: (0@0).
   m addMorph: a

Cranky»initialize
   f := Form fromFileNamed: 'hot_air_balloon_mysticmorning.jpg'.
   m := ImageMorph new.
   m form: f.
   self initA.
   m openInWindowLabeled: 'Cranky'.
   delay := (Delay forSeconds: 5).
   [ [ true ] whileTrue: [ a contents: 0 asString. delay wait ] fork

I can run this application for hours and hours with no problem. However, if I run it for a while and then close the application and then save/exit the image, the next time I start the image, there is some likelihood it will crash dump. The probability is something like 5-10%.

Interestingly, if I remove the statement...

a contents: 0 asString.

from the infinite loop, I've not been able to replicate the crash. Is there something wrong with the way I'm updating the contents of the StringMorph?

I'm using Pharo 5.0.

I'm using the Spur VM for Raspberry Pi.

I'm running under Raspbian (Debian).

Denis Kudriashov wrote

2017-05-31 16:24 GMT+02:00 horrido <[hidden email]>:

> Oh, I forgot to mention, the crash dump says I got a segmentation fault.


This is of course needs attention. What pharo you are using? what VM,
images, OS?

I tried UIManager default defer: but I still got an intermittent crash. Good suggestion, though. Maybe it's not related to Morphic not being thread-safe?

Denis Kudriashov wrote

Hi Horrido.

Morphic is not thread safe library. Users should not update morphs state
directly from background processes. Use #defer: message to update morphs in
such cases.
Try following loop:

  [ [ true ] whileTrue: [ UIManager default defer: [ a contents: 0
asString]. delay wait ] fork



2017-05-31 16:23 GMT+02:00 horrido <[hidden email]>:

> I have a puzzling bug. I've narrowed the scenario down to this code:
>
> Cranky»initA
>    a := ((StringMorph contents: '####') color: Color white) position: (0@0
> ).
>    m addMorph: a
>
> Cranky»initialize
>    f := Form fromFileNamed: 'hot_air_balloon_mysticmorning.jpg'.
>    m := ImageMorph new.
>    m form: f.
>    self initA.
>    m openInWindowLabeled: 'Cranky'.
>    delay := (Delay forSeconds: 5).
>    [ [ true ] whileTrue: [ a contents: 0 asString. delay wait ] fork
>
> I can run this application for hours and hours with no problem. However, if
> I run it for a while and then close the application and then save/exit the
> image, the next time I start the image, there is some likelihood it will
> crash dump. The probability is something like 5-10%.
>
> Interestingly, if I remove the statement...
>
> a contents: 0 asString.
>
> from the infinite loop, I've not been able to replicate the crash. Is there
> something wrong with the way I'm updating the contents of the StringMorph?
>
>
>
> --
> View this message in context: http://forum.world.st/Morphic-
> or-forking-bug-tp4948727.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>

Alternatively use the step protocol of the Morph class. I think it is
documented in the Pharo by example book.

Hilaire


Le 31/05/2017 à 17:00, Denis Kudriashov a écrit :
--
Dr. Geo
http://drgeo.eu

Thanks, Hilaire. I had high hopes for your suggestion.

But after testing a few times, Pharo crashed again.

So the step protocol doesn't solve the problem, either.

HilaireFernandes wrote

Alternatively use the step protocol of the Morph class. I think it is
documented in the Pharo by example book.

Hilaire


Le 31/05/2017 à 17:00, Denis Kudriashov a écrit :
> Hi Horrido.
>
> Morphic is not thread safe library. Users should not update morphs
> state directly from background processes. Use #defer: message to
> update morphs in such cases.
> Try following loop:
>
>   [ [ true ] whileTrue: [ UIManager default defer: [ a contents: 0
> asString]. delay wait ] fork
>
>

--
Dr. Geo
http://drgeo.eu

In that case the problem is really somewhere else. I use step since
years in DrGeo to get selected geometric shapes to blink. May be your
problem is related to the use of processes.

Hilaire


Le 01/06/2017 à 00:27, horrido a écrit :
> Thanks, Hilaire. I had high hopes for your suggestion.
>
> But after testing a few times, Pharo crashed again.
>
> So the step protocol doesn't solve the problem, either.
>

--
Dr. Geo
http://drgeo.eu

See below for the crash dump.

Guillermo Polito wrote

Horrido,

Can you also provide the stack associated with the segmentation fault?
Usually the VM captures the signal and dumps the current stack at the
moment of the crash in stdout. You'll find the same stack in the file
crash.dmp.

On Thu, Jun 1, 2017 at 6:51 AM, Ben Coman <[hidden email]> wrote:

>
>
> On Wed, May 31, 2017 at 10:23 PM, horrido <[hidden email]>
> wrote:
>
>> I have a puzzling bug. I've narrowed the scenario down to this code:
>>
>> Cranky»initA
>>    a := ((StringMorph contents: '####') color: Color white) position: (0@0
>> ).
>>    m addMorph: a
>>
>> Cranky»initialize
>>    f := Form fromFileNamed: 'hot_air_balloon_mysticmorning.jpg'.
>>    m := ImageMorph new.
>>    m form: f.
>>    self initA.
>>    m openInWindowLabeled: 'Cranky'.
>>    delay := (Delay forSeconds: 5).
>>    [ [ true ] whileTrue: [ a contents: 0 asString. delay wait ] fork
>>
>> I can run this application for hours and hours with no problem. However,
>> if
>> I run it for a while and then close the application and then save/exit the
>> image, the next time I start the image, there is some likelihood it will
>> crash dump. The probability is something like 5-10%.
>>
>> Interestingly, if I remove the statement...
>>
>> a contents: 0 asString.
>>
>> from the infinite loop, I've not been able to replicate the crash. Is
>> there
>> something wrong with the way I'm updating the contents of the StringMorph?
>>

Segmentation fault Thu Jun  1 09:04:56 2017


/home/pi/pharo50-dev/lib/pharo/5.0-201705051953/pharo
Pharo VM version: 5.0-201705051953  Fri May  5 21:02:28 UTC 2017 gcc 4.9.2 [Production Spur VM]
Built from: CoInterpreter VMMaker.oscog-eem.2207 uuid: 8da5de9b-33d7-478b-9081-58591f7da69a May  5 2017
With: StackToRegisterMappingCogit VMMaker.oscog-eem.2208 uuid: 4877be7d-941d-4e15-b6df-4f1b8c7072a8 May  5 2017
Revision: VM: 201705051953 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Fri May 5 12:53:38 2017 -0700 $
Plugins: 201705051953 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Build host: Linux testing-gce-4db3c1dc-5576-4a70-9128-5f5e3d62217a 4.4.0-62-generic #83~14.04.1-Ubuntu SMP Wed Jan 18 18:10:30 UTC 2017 armv7l GNU/Linux
plugin path: ./lib/pharo/5.0-201705051953 [default: /home/pi/pharo50-dev/lib/pharo/5.0-201705051953/]


C stack backtrace & registers:
         r0 0x75d94008 r1 0x74d7ca00 r2 0x00000000 r3 0x75f45000
         r4 0x004089d8 r5 0x76fe6f10 r6 0x7e8586ec r7 0x00000003
         r8 0x00000000 r9 0x75f44298 r10 0x7e8586ec fp 0x74746366
         ip 0x00000000 sp 0x7e858678 lr 0x00047c44 pc 0x75ebe478
*[0x0]
[0x7e8572a0]


Smalltalk stack dump:
0x7e85c864 I FreeTypeFace(FT2Face)>newFaceFromExternalMemory:index: 0x3457050: a(n) FreeTypeFace
0x7e85c88c I FreeTypeFace>create 0x3457050: a(n) FreeTypeFace
0x7e85c8ac I FreeTypeFace>validate 0x3457050: a(n) FreeTypeFace
0x7e85c8cc I FreeTypeFont>face 0x765b18: a(n) FreeTypeFont
0x7e85c908 I FreeTypeFontProvider>fontFor:familyName: 0x11d4450: a(n) FreeTypeFontProvider
0x7e85c934 M [] in LogicalFontManager>bestFontFor:whenFindingAlternativeIgnoreAll: 0x12db5b0: a(n) LogicalFontManager
0x7e85c958 M OrderedCollection>do: 0x12db5c0: a(n) OrderedCollection
0x7e85c97c M [] in LogicalFontManager>bestFontFor:whenFindingAlternativeIgnoreAll: 0x12db5b0: a(n) LogicalFontManager
0x7e85c9a0 M Array(SequenceableCollection)>do: 0x7649d8: a(n) Array
0x7e85c9c8 I LogicalFontManager>bestFontFor:whenFindingAlternativeIgnoreAll: 0x12db5b0: a(n) LogicalFontManager
0x7e85c9f0 I LogicalFontManager>bestFontFor: 0x12db5b0: a(n) LogicalFontManager
0x7e85ca14 I LogicalFont>findRealFont 0x12db578: a(n) LogicalFont
0x7e85ca34 I LogicalFont>realFont 0x12db578: a(n) LogicalFont
0x7e85ca54 I LogicalFont>widthOfString: 0x12db578: a(n) LogicalFont
0x7e85ca7c I StringMorph>measureContents 0x325a480: a(n) StringMorph
0x7e85caa4 I StringMorph>fitContents 0x325a480: a(n) StringMorph
0x7e85cac4 I StringMorph>contents: 0x325a480: a(n) StringMorph
0x7e85cae8 I [] in Cranky>initialize 0x325a390: a(n) Cranky
 0x325a408 s [] in BlockClosure>newProcess

Most recent primitives
class
class
class
class
+
**PrimitiveFailure**
digitAdd:
normalize
class
primUTCMicrosecondsClock
at:
+
at:
at:
at:
+
signal
primSignalAtBytesLeft:
suspend
class
scanFor:
scanFor:
scanFor:
basicAt:
isNil
isNil
findNextUnwindContextUpTo:
findContextSuchThat:
valueNoContextSwitch
valueNoContextSwitch
**StackOverflow**
at:
objectAt:
class
header
basicNew:
stackp:
at:
at:put:
valueNoContextSwitch
value
stackp:
at:put:
at:
stackp:
valueNoContextSwitch
ensure:
ensure:
ensure:
ensure:
stackp:
at:put:
at:
stackp:
findNextUnwindContextUpTo:
terminateTo:
value
stackp:
at:put:
at:
stackp:
at:
value
at:
stackp:
findNextUnwindContextUpTo:
at:put:
at:put:
stackp:
at:put:
stepToCallee
stepToCallee
stepToCallee
stepToCallee
at:
stackp:
at:
stackp:
at:put:
at:
stackp:
return:from:
return:from:
at:put:
at:put:
stackp:
at:put:
at:
class
bitAnd:
bitAnd:
bitAnd:
numCopiedValues
stackp:
numCopiedValues
priority:
primitiveResume
garbageCollectMost
**IncrementalGC**
at:put:
basicNew
primLowSpaceSemaphore:
primSignalAtBytesLeft:
wait
compare:with:collated:
class
stringHash:initialHash:
at:
basicNew
new:
value:
value
basicNew
value
primCurrentLibrary
hash
compare:with:collated:
value:
at:
at:
value:value:
**StackOverflow**
**StackOverflow**
closenessVectorForStretch:slant:weight:
*
*
*
*
*
**StackOverflow**
class
second
**StackOverflow**
raisedTo:
raisedTo:
raisedTo:
raisedTo:
raisedTo:
raisedTo:
at:
third
asFloat
sqrt
truncated
sqrt
sqrt
=
=
=
=
=
bitShift:
**PrimitiveFailure**
bitShiftMagnitude:
timesTwoPower:
>=
at:
value:value:
value:value:
**StackOverflow**





truncated





truncated
value:value:
**StackOverflow**
truncated
truncated

**PrimitiveFailure**
bitShiftMagnitude:
timesTwoPower:


**PrimitiveFailure**
basicAt:
basicAt:
bitShift:
**PrimitiveFailure**
bitShiftMagnitude:
basicAt:
+
bitOr:
digitCompare:
digitAt:
digitAt:
at:
bitShiftMagnitude:
bitShift:
**PrimitiveFailure**
bitShiftMagnitude:
basicNew
=
=
<
perform:with:
<
**PrimitiveFailure**
perform:with:
denominator
**PrimitiveFailure**
digitMultiply:neg:
numerator
numerator
at:
value:value:
**StackOverflow**
truncated
truncated
at:
value:value:
truncated
truncated
value:value:
value:value:
value:value:
value:value:
value:value:
value:value:
value:value:
value:value:
value:value:
value:value:
at:
at:
at:put:
at:put:
at:
value:value:
truncated
truncated
sort:to:
sort:to:
sort:to:
sort:to:
truncated
truncated
truncated
truncated
bitShiftMagnitude:
timesTwoPower:
basicNew
allInstancesOrNil
value:
index
value:
size
primNewFaceFromExternalMemory:size:index:

stack page bytes 4096 available headroom 2788 minimum unused headroom 3036

        (Segmentation fault)

I downloaded Pharo 6.0 but used the same Spur VM (which I presume is still the latest for Raspberry Pi): http://files.pharo.org/vm/pharo-spur32/linux/armv6/pharo-linux-ARMv6-201705051953-b8db6de.zip

It crashed, too.

Denis Kudriashov wrote

2017-05-31 17:57 GMT+02:00 horrido <[hidden email]>:

> I'm using  Pharo 5.0


I test it with Pharo 6 (latest image and VM) and have no problem. Could you
check it too?

Here is something I found by accident...

If I run my app, then close it, then save/exit the image, then open the image again, edit my application class to add a new instance variable, then save the change – Pow! – I get about a dozen debugger pop-ups saying "#wait was sent to nil".

What this tells me (and you may correct me if I'm wrong), the VM still has a thread running that is sending #wait messages to my application which has already shutdown. This can't be good, but whether this is related to the segmentation fault is anybody's guess at this point.

Stephane Ducasse-3 wrote

Thanks for reporting.
I hope that in Pharo 70 we will get rid of the FreeType pluging.

Stef

On Thu, Jun 1, 2017 at 3:30 PM, horrido <[hidden email]> wrote:

> I downloaded Pharo 6.0 but used the same Spur VM (which I presume is still
> the latest for Raspberry Pi):
> http://files.pharo.org/vm/pharo-spur32/linux/armv6/pharo-linux-ARMv6-
> 201705051953-b8db6de.zip
>
> It crashed, too.
>
>
> Denis Kudriashov wrote
> > 2017-05-31 17:57 GMT+02:00 horrido <
>
> > horrido.hobbies@
>
> > >:
> >
> >> I'm using  Pharo 5.0
> >
> >
> > I test it with Pharo 6 (latest image and VM) and have no problem. Could
> > you
> > check it too?
>
>
>
>
>
> --
> View this message in context: http://forum.world.st/Morphic-
> or-forking-bug-tp4948727p4948818.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>
>

Yup, they all fail. Interesting that 0 asString fails. This means it has NOTHING to do with Morphic (or Morphic being thread-unsafe).

Ben Coman wrote

On Wed, May 31, 2017 at 10:23 PM, horrido <[hidden email]> wrote:

Can you try a few other variations...
   [ [ true ] whileTrue: [ 0 asString. delay wait ] fork.
   [ [ true ] whileTrue: [ a contents: '0'. delay wait ] fork.
   [ [ true ] whileTrue: [ a contents: '0'. ] forkAt: 20.

cheers -ben

Sorry, I could be mistaken. I just checked my notes. The 0 asString test failed once, but I've not been able to replicate it. I might've been working with an unclean image.

So perhaps it is related to Morphic, after all.

horrido wrote

Yup, they all fail. Interesting that 0 asString fails. This means it has NOTHING to do with Morphic (or Morphic being thread-unsafe).

Ben Coman wrote

On Wed, May 31, 2017 at 10:23 PM, horrido <[hidden email]> wrote:

Can you try a few other variations...
   [ [ true ] whileTrue: [ 0 asString. delay wait ] fork.
   [ [ true ] whileTrue: [ a contents: '0'. delay wait ] fork.
   [ [ true ] whileTrue: [ a contents: '0'. ] forkAt: 20.

cheers -ben

Hi Horrido,

It is very hard to follow what you are exactly doing or trying to do.

Here is the simplest example I can think of that updates something in Morphic on a regular basis.

StringMorph subclass: #MyClock
        instanceVariableNames: ''
        classVariableNames: ''
        package: '_UnpackagedPackage'

MyClock>>#initialize
        super initialize.
        self updateClock

MyClock>>#step
        self updateClock

MyClock>>#updateClock
        self contents: Time now printString

MyClock class>>#open
        "self open"
       
        ^ self new openInWindow

This inherits #stepTime as 1 second. If I open such a window and save my image, it is still there when the image is restarted, with the clock still working.

Updating (data structures in) the main UI process from another process is dangerous. Saving such constructs is even more dangerous.

HTH,

Sven