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.
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?
-- View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4948728.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
I'm using Pharo 5.0 <https://medium.com/r/?url=http%3A%2F%2Ffiles.pharo.org%2Fimage%2F40%2Flatest...> . I'm using the Spur VM for Raspberry Pi <https://medium.com/r/?url=http%3A%2F%2Ffiles.pharo.org%2Fvm%2Fpharo-spur32%2...> . I'm running under Raspbian (Debian). Denis Kudriashov wrote
2017-05-31 16:24 GMT+02:00 horrido <
horrido.hobbies@
>:
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?
-- View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4948742.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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-2017050... 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.
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 <horrido.hobbies@gmail.com> 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.
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 <
horrido.hobbies@
> 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.
-- View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4948911.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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 <horrido.hobbies@gmail.com>:
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.
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 <
horrido.hobbies@
>:
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.
-- View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4948753.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 :
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
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
-- View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4948774.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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
On Wed, May 31, 2017 at 10:23 PM, horrido <horrido.hobbies@gmail.com> 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?
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
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 <btc@openinworld.com> wrote:
On Wed, May 31, 2017 at 10:23 PM, horrido <horrido.hobbies@gmail.com> 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?
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
-- Guille Polito Research Engineer French National Center for Scientific Research - *http://www.cnrs.fr* <http://www.cnrs.fr> *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13
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 <
btc@
> wrote:
On Wed, May 31, 2017 at 10:23 PM, horrido <
horrido.hobbies@
>
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) -- View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4948806.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 <
horrido.hobbies@
> 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
-- View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4948983.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Yup, they all fail. Interesting that
0 asString
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 * *
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 <
horrido.hobbies@
> 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
-- View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4948984.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
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
On 2 Jun 2017, at 15:54, horrido <horrido.hobbies@gmail.com> wrote:
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.
Yup, they all fail. Interesting that
0 asString
horrido wrote * *
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 <
horrido.hobbies@
> 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
-- View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4948984.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Okay, let me explain my application... It displays a Morphic window containing lines of information that are updateable in real time on a periodic basis. As I indicated in the original post, the code skeleton is basically: initA a := ((StringMorph contents: '####') color: Color white) position: (0@0). m addMorph: a 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 Imagine that #initA creates many such StringMorphs, each displaying a different kind of information. In the endless loop, imagine that instead of 'a contents: 0 asString', I'm updating all of the StringMorphs I created in #initA. The need to do this in a separate thread is to prevent Pharo from being completely frozen during the 'delay wait', which is practically all the time! Now, I did try Hilaire's suggestion to use Morphic's step protocol instead. But in my test scenario of closing the app/saving and exiting the image/restarting the image, repeatedly (in may take 10-20 times), it still causes the occasional segmentation fault. So if the problem is updating a structure in the main thread from another process, then why did Hilaire's suggestion not solve the problem? It seems to me, then, either way, it's an issue of multithreading...whether my way or Hilaire's way. Sven Van Caekenberghe-2 wrote
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
On 2 Jun 2017, at 15:54, horrido <
horrido.hobbies@
> wrote:
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.
Yup, they all fail. Interesting that
0 asString
horrido wrote * *
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 <
horrido.hobbies@
> 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
-- View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4948984.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
-- View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4949166.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
You are mixing 3 different aspects: - how to update a UI from a background process - how to maintain a background process over image save/open - how to communicate between the 2 Safe UI updating has to happen using #step or #defer: and should be quick/short as not to block the UI. Although processes survive over image save/open (provided they did not become garbage), this is dangerous as they come up immediately (too soon) and will probably hold external resources (files/sockets/..) that will have changed (and result in a crash). It is better to manage this explicitly using #startUp and #shutDown. Communication between the 2 should be protected using a semaphore. Here is an example of a 'file watcher', a little window that shows the first line of a specific file, updating it every 3 seconds (silly and too resource intensive, it is just a demo). You can edit the file manually to modify the contents of the first line and see it being picked up in Pharo (within 3 seconds). Here is the code as 1 file/class in '_UnpackagedPackage': See the class side #initialize for the #startUp and #shutDown registration, sent to all instances as #start and #stop (a bit rude but good enough for the demo). Instance side #initialize sets up the mutex that gets used in the #firstLine and #firstLine: accessors. The actual process is in #run which calls #updateFirstLine The UI updating is in #step which calls #updateFileLineDisplay Subscribing to MorphDeleted via the announcer allows for the process to stop when the window closes. The file watcher window and process survive an image save/open (i.e. they keep on working). HTH, Sven
On 3 Jun 2017, at 15:44, horrido <horrido.hobbies@gmail.com> wrote:
Okay, let me explain my application...
It displays a Morphic window containing lines of information that are updateable in real time on a periodic basis. As I indicated in the original post, the code skeleton is basically:
initA a := ((StringMorph contents: '####') color: Color white) position: (0@0). m addMorph: a
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
Imagine that #initA creates many such StringMorphs, each displaying a different kind of information.
In the endless loop, imagine that instead of 'a contents: 0 asString', I'm updating all of the StringMorphs I created in #initA.
The need to do this in a separate thread is to prevent Pharo from being completely frozen during the 'delay wait', which is practically all the time!
Now, I did try Hilaire's suggestion to use Morphic's step protocol instead. But in my test scenario of closing the app/saving and exiting the image/restarting the image, repeatedly (in may take 10-20 times), it still causes the occasional segmentation fault.
So if the problem is updating a structure in the main thread from another process, then why did Hilaire's suggestion not solve the problem?
It seems to me, then, either way, it's an issue of multithreading...whether my way or Hilaire's way.
Sven Van Caekenberghe-2 wrote
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
On 2 Jun 2017, at 15:54, horrido <
horrido.hobbies@
> wrote:
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.
Yup, they all fail. Interesting that
0 asString
horrido wrote * *
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 <
horrido.hobbies@
> 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
-- View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4948984.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
-- View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4949166.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
Sven's Clock example. Just unzip & file in. MyClock.zip <http://forum.world.st/file/n4949170/MyClock.zip> Best Regards, Milan Vavra -- View this message in context: http://forum.world.st/Morphic-or-forking-bug-tp4948727p4949170.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
participants (8)
-
Ben Coman -
Denis Kudriashov -
Guillermo Polito -
Hilaire -
horrido -
Milan Vavra -
Stephane Ducasse -
Sven Van Caekenberghe