VM crash from triple 'Smalltalk garbageCollect' then forked Transcript stress test

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

VM crash from triple 'Smalltalk garbageCollect' then forked Transcript stress test

Ben Coman
 
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

report.zip (17K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: VM crash from triple 'Smalltalk garbageCollect' then forked Transcript stress test

Eliot Miranda-2
 
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 <[hidden email]> 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




--
best,
Eliot
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] [Vm-dev] VM crash from triple 'Smalltalk garbageCollect' then forked Transcript stress test

Ben Coman
 
Eliot Miranda wrote:
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.

Thanks Eliot.  I vaguely knew about your preference there, but I wasn't sure of the mechanism.  In a fresh image, I ran my snippet below, one time, then ran it again preceded by "Smalltalk snapshot: true andQuit: true"

You probably don't need the OSX Pharo-VM included, but I've included it for completeness. 
    http://files.openinworld.com/Pharo/Pharo-Case-13822.zip
If you do...
        ./pharo-ui Pharo.image
it crashes about 70% of the time.

For comparison I tried my snippet on Squeak-4.5-All-In-One, but the Transcript instead goes Red-Morph-Of-Death the same as Pharo used to.  I didn't try to mix-n-match VMs since my vague understanding is that the Pharo Image doesn't work with them out of the box.

cheers -ben



On Sun, Aug 10, 2014 at 7:31 AM, Ben Coman <[hidden email]> 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




--
best,
Eliot