Hi Ben,

I'll try and take a look at this, but it'll really make things easier to do that if you create an image that runs the snipped from startup. e.g. evaluate the snipped preceded by Smalltalk snapshot: true andQuit: true Launch and if the VM doesn't crash rinse and repeat changing the snippet until the VM does crash on startup without user intervention. It's much easier to debug then.

Then put that image & changes somewhere and email me the URL.

On Sun, Aug 10, 2014 at 7:31 AM, Ben Coman btc@openinworld.com wrote:

For Pharo I found the following snippet crashes the VM with fresh images.

Smalltalk garbageCollect. Smalltalk garbageCollect. Smalltalk garbageCollect. Transcript open. [ Transcript crShow: ( [ | string | string := '-'. 1 to: 2000 do: [ :n | string := string , '-', n printString. Transcript show: string. ]. (Delay forMilliseconds: 10) wait. ]) timeToRun. ] fork.

Over a dozen runs, this usually occurred on the second evaluation of that snippet, and once each on the third and fourth evaluation of that snippet.

If there is only a single 'Smalltalk garbageCollect' rather than the three, then the VM doesn't crash. (Aside: I don't really know what use running it three times is, I just see it down elsewhere.)

I recorded four runs. run1, run2, run3 were with... $ curl get.pharo.org/alpha+vmLatest | bash and run4 with... $ curl get.pharo.org/30+vmLatest | bash

Console logs and crash.dmp attached.

---

All four runs show the same crash info at top...

Segmentation fault Sun Aug 10 21:17:09 2014 C stack backtrace: 0 Pharo 0x0004c0ef reportStackState + 159

---

and bottom...

  (Segmentation fault)

./pharo-ui: line 11: 21593 Abort trap: 6 "$DIR"/"pharo-vm/Pharo.app/Contents/MacOS/Pharo" "$@"

---

but different stack dumps... ---------run1 Smalltalk stack dump: 0xbffb68e4 M SmallInteger(Integer)>timesRepeat: 0x1=0 0xbffb6900 M CompositionScanner(CharacterScanner)>handleIndentation 0x2300ced4: a(n) CompositionScanner 0xbffb6920 M CompositionScanner>composeFrom:inRectangle:firstLine:leftSide:rightSide: 0x2300ced4: a(n) CompositionScanner 0xbffb695c M TextComposer>composeEachRectangleIn: 0x21f2a340: a(n) TextComposer ---------run2 Smalltalk stack dump: 0xbffb7868 M BlockClosure>on:do: 0x21ff5a64: a(n) BlockClosure 0xbffb7888 M BlockClosure>on:fork: 0x21ff5a64: a(n) BlockClosure 0xbffb78a8 M WeakAnnouncementSubscription>deliver: 0x20e20260: a(n) WeakAnnouncementSubscription 0xbffb78cc M [] in SubscriptionRegistry>deliver:to:startingAt: 0x20e1e688: a(n) SubscriptionRegistry 0xbffb78ec M BlockClosure>ifCurtailed: 0x21ff59d4: a(n) BlockClosure ---------run3 0xbfff204c M SmalltalkImage>garbageCollect 0x1fd577c4: a(n) SmalltalkImage 0xbfff2064 M UndefinedObject>(nil) 0x1f500004: a(n) UndefinedObject 0xbfff2094 I OpalCompiler>evaluate 0x220c1184: a(n) OpalCompiler 0xbfff20c0 I SmalltalkEditor>evaluateSelectionAndDo: 0x20b2e930: a(n) SmalltalkEditor 0xbfff20e4 I SmalltalkEditor>evaluateSelection 0x20b2e930: a(n) SmalltalkEditor 0xbfff2104 I [] in PluggableTextMorph>doIt 0x20b18014: a(n) PluggableTextMorph ---------run4 Smalltalk stack dump: 0xbffb501c I SmalltalkImage>garbageCollect 0x1f969748: a(n) SmalltalkImage 0xbffb5034 M UndefinedObject>(nil) 0x1f500004: a(n) UndefinedObject 0xbffb5064 I OpalCompiler>evaluate 0x21eebda0: a(n) OpalCompiler 0xbffb5090 I SmalltalkEditor>evaluateSelectionAndDo: 0x20970488: a(n) SmalltalkEditor 0xbffb50b4 I SmalltalkEditor>evaluateSelection 0x20970488: a(n) SmalltalkEditor 0xbffb50d4 I [] in PluggableTextMorph>doIt 0x209587f0: a(n) PluggableTextMorph

---

Maybe its Image code doing bad things rather than a VM bug, but I'm not qualified to tell. Also I'm working on removing ThreadSafeTranscriptPluggableTextMorph which wraps #update: and #drawOn: with a mutex to avoid the same snippet causing a Red-Morph-Of-Death, so maybe those changes will bypass the bug, but thought this report might be generally useful if it flushed out some corner case.

I'll copy any mail list discussion to https://pharo.fogbugz.com/default.asp?13822. cheers -ben