Vm-dev August 2018

vm-dev@lists.squeakfoundation.org

20 participants
87 discussions

[OpenSmalltalk/opensmalltalk-vm] a28a75: Add FileAttributesPlugin as an external plugin to ...
by GitHub 08 Aug '18

08 Aug '18

Branch: refs/heads/Cog Home: https://github.com/OpenSmalltalk/opensmalltalk-vm Commit: a28a7546d6dc8e1f366c5f9848c78e5fad400547 https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/a28a7546d6dc8e1f36… Author: Eliot Miranda <eliot.miranda(a)gmail.com> Date: 2018-08-08 (Wed, 08 Aug 2018) Changed paths: M build.linux32ARMv6/squeak.cog.spur/plugins.ext M build.linux32ARMv6/squeak.stack.spur/plugins.ext M build.linux32ARMv6/squeak.stack.v3/plugins.ext M build.linux32x86/squeak.cog.spur.immutability/plugins.ext M build.linux32x86/squeak.cog.spur/plugins.ext M build.linux32x86/squeak.cog.v3/plugins.ext M build.linux32x86/squeak.sista.spur/plugins.ext M build.linux32x86/squeak.stack.spur/plugins.ext M build.linux32x86/squeak.stack.v3/plugins.ext M build.linux64x64/squeak.cog.spur.immutability/plugins.ext M build.linux64x64/squeak.cog.spur/plugins.ext M build.linux64x64/squeak.stack.spur/plugins.ext M build.macos32x86/squeak.cog.spur+immutability/plugins.ext M build.macos32x86/squeak.cog.spur/plugins.ext M build.macos32x86/squeak.cog.v3/plugins.ext M build.macos32x86/squeak.sista.spur/plugins.ext M build.macos32x86/squeak.stack.spur/plugins.ext M build.macos32x86/squeak.stack.v3/plugins.ext M build.macos64x64/squeak.cog.spur.immutability/plugins.ext M build.macos64x64/squeak.cog.spur/plugins.ext M build.macos64x64/squeak.sista.spur/plugins.ext M build.macos64x64/squeak.stack.spur/plugins.ext M build.win32x86/squeak.cog.spur.lowcode/plugins.ext M build.win32x86/squeak.cog.spur/plugins.ext M build.win32x86/squeak.cog.v3/plugins.ext M build.win32x86/squeak.sista.spur/plugins.ext M build.win32x86/squeak.stack.spur/plugins.ext M build.win32x86/squeak.stack.v3/plugins.ext M build.win64x64/squeak.cog.spur/plugins.ext M build.win64x64/squeak.stack.spur/plugins.ext Log Message: ----------- Add FileAttributesPlugin as an external plugin to the Squeak builds. **NOTE:** This service has been marked for deprecation: https://developer.github.com/changes/2018-04-25-github-services-deprecation/ Functionality will be removed from GitHub.com on January 31st, 2019.

1 0

[OpenSmalltalk/opensmalltalk-vm] CoverageWrapper VM crash Squeak (#267)
by Jascha Beste 08 Aug '18

08 Aug '18

By enabling coverage reporting in SmalltalkCI (with a new VMVersion) the VM crashes when calling some specific methods on the coverage wrapper, I think. To reproduce you can checkout the acceptit projects repository here: https://github.com/hpi-swa-teaching/AcceptIt Here's the error message the crash resulted in: ``` Segmentation fault Tue Jun 12 17:53:59 2018 ../sqcogspurlinuxht/lib/squeak/5.0-201804030952/squeak Squeak VM version: 5.0-201804030952 Tue Apr 3 17:18:11 UTC 2018 gcc 4.8 [Production Spur VM] Built from: CoInterpreter VMMaker.oscog-eem.2361 uuid: 7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr 3 2018 With: StackToRegisterMappingCogit VMMaker.oscog-eem.2361 uuid: 7ca2f89a-de70-422f-b92b-54f91ac4e47b Apr 3 2018 Revision: VM: 201804030952 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Tue Apr 3 11:52:19 2018 +0200 $ CommitHash: 29f50cf $ Plugins: 201804030952 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Build host: Linux travis-job-930f7414-a090-41ce-93a1-0feed6bb9e53 4.4.0-101-generic #124~14.04.1-Ubuntu SMP Fri Nov 10 19:05:36 UTC 2017 i686 i686 i686 GNU/Linux plugin path: ..sqcogspurlinuxht/bin/../lib/squeak/5.0-201804030952 [default: ../sqcogspurlinuxht/lib/squeak/5.0-201804030952/] C stack backtrace & registers: eax 0xfff009e4 ebx 0xfff00900 ecx 0xfff00998 edx 0xfff0094c edi 0xfff007d0 esi 0xfff007d0 ebp 0xfff00868 esp 0xfff008b4 eip 0xfff00ac8 *[0xfff00ac8] /../lib/squeak/5.0-201804030952/squeak[0x805ef8a] /../lib/squeak/5.0-201804030952/squeak[0x8060ada] [0xf774cbd0] /../lib/squeak/5.0-201804030952/squeak(interpret+0x2eb)[0x809a1cb] /../lib/squeak/5.0-201804030952/squeak[0x80a39ee] /../lib/squeak/5.0-201804030952/squeak(interpret+0x1e3)[0x809a0c3] /../lib/squeak/5.0-201804030952/squeak(main+0x2f7)[0x805e467] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf7)[0xf7534637] /../lib/squeak/5.0-201804030952/squeak[0x805e7bf] [0xffffffff] Smalltalk stack dump: 0xfff06a68 I Message>(nil) 0x9046f58: a(n) Message 0xfff06a84 M [] in ACCalculatorUserStory class(ACUserStory class)>scenarioAndMethodDict 0xad3dbb8: a(n) ACCalculatorUserStory class 0xfff06aac M [] in MethodDictionary(Collection)>inject:into: 0xb618738: a(n) MethodDictionary 0xfff06ad4 M MethodDictionary>valuesDo: 0xb618738: a(n) MethodDictionary 0xfff06af0 M MethodDictionary(Dictionary)>do: 0xb618738: a(n) MethodDictionary 0xfff06b10 M MethodDictionary(Collection)>inject:into: 0xb618738: a(n) MethodDictionary 0xfff06b30 M ACCalculatorUserStory class(ACUserStory class)>scenarioAndMethodDict 0xad3dbb8: a(n) ACCalculatorUserStory class 0xfff06b48 M ACCalculatorUserStory class(ACUserStory class)>compiledMethodAt: 0xad3dbb8: a(n) ACCalculatorUserStory class 0xfff06b64 M SCICoverageWrapper>run:with:in: 0xad17488: a(n) SCICoverageWrapper 0xfff06b8c M ACTestRunner>stepList 0xb618b20: a(n) ACTestRunner 0xfff06ba4 M ACPluggableListMorphPlus(PluggableListMorph)>getFullList 0xb61e088: a(n) ACPluggableListMorphPlus 0xfff06bbc M ACPluggableListMorphPlus(PluggableListMorph)>getList 0xb61e088: a(n) ACPluggableListMorphPlus 0xfff06bd4 M ACPluggableListMorphPlus(PluggableListMorph)>getListSize 0xb61e088: a(n) ACPluggableListMorphPlus 0xfff06bec M LazyListMorph>getListSize 0xb64f168: a(n) LazyListMorph 0xfff06c08 M LazyListMorph>listChanged 0xb64f168: a(n) LazyListMorph 0xfff06c24 M ACPluggableListMorphPlus(PluggableListMorph)>updateList 0xb61e088: a(n) ACPluggableListMorphPlus 0xfff06c44 M ACPluggableListMorphPlus(PluggableListMorph)>update: 0xb61e088: a(n) ACPluggableListMorphPlus 0xfff06c64 M [] in ACTestRunner(Object)>changed: 0xb618b20: a(n) ACTestRunner 0xfff06c8c M DependentsArray>do: 0xb618e48: a(n) DependentsArray 0xfff01a4c M ACTestRunner(Object)>changed: 0xb618b20: a(n) ACTestRunner 0xfff01a70 I ACTestRunner>updateSteps 0xb618b20: a(n) ACTestRunner 0xfff01a88 M ACTestRunner>scenarioAt:put: 0xb618b20: a(n) ACTestRunner 0xfff01aa8 M SCICoverageWrapper>run:with:in: 0xad16f78: a(n) SCICoverageWrapper 0xfff01acc M ACTestRunner(Object)>perform:with:with: 0xb618b20: a(n) ACTestRunner 0xfff01af0 M PluggableListMorphOfMany>listSelectionAt:put: 0xb61e1f0: a(n) PluggableListMorphOfMany 0xfff01b28 I PluggableListMorphOfMany>mouseDown: 0xb61e1f0: a(n) PluggableListMorphOfMany 0xfff01b4c I PluggableListMorphOfMany(Morph)>handleMouseDown: 0xb61e1f0: a(n) PluggableListMorphOfMany 0xfff01b68 M MouseButtonEvent>sentTo: 0x9033038: a(n) MouseButtonEvent 0xfff01b84 M PluggableListMorphOfMany(Morph)>handleEvent: 0xb61e1f0: a(n) PluggableListMorphOfMany 0xfff01bac M [] in MTFMorphWrapper>sendMouseEvent:button:modifiers: 0x9032d88: a(n) MTFMorphWrapper 0xfff01bd0 M Array(SequenceableCollection)>do: 0x9032d78: a(n) Array 0xfff01bec M MTFMorphWrapper>sendMouseEvent:button:modifiers: 0x9032d88: a(n) MTFMorphWrapper 0xfff01c18 I MTFMorphWrapper>mouseDownForButton:with: 0x9032d88: a(n) MTFMorphWrapper 0xfff01c40 I MTFMorphWrapper>leftMouseDown: 0x9032d88: a(n) MTFMorphWrapper 0xfff01c64 M [] in MTFMorphWrapper>leftClickWith: 0x9032a70: a(n) MTFMorphWrapper 0xfff01c8c M Set>do: 0x8e9d5c0: a(n) Set 0xfff0c8c0 M MTFMorphWrapper>leftClickWith: 0x9032a70: a(n) MTFMorphWrapper 0xfff0c8dc M MTFMorphWrapper>leftClick 0x9032a70: a(n) MTFMorphWrapper 0xfff0c8fc I MTFMorphWrapper>click 0x9032a70: a(n) MTFMorphWrapper 0xfff0c91c I ACTestRunnerTest>selectCorrectScenario 0xad23ef0: a(n) ACTestRunnerTest 0xfff0c938 M ACTestRunnerTest>testDisplaysScenario 0xad23ef0: a(n) ACTestRunnerTest 0xfff0c958 I ACTestRunnerTest(TestCase)>performTest 0xad23ef0: a(n) ACTestRunnerTest 0xfff0c970 M [] in ACTestRunnerTest(TestCase)>runCase 0xad23ef0: a(n) ACTestRunnerTest 0xfff0c98c M BlockClosure>on:do: 0xb680420: a(n) BlockClosure 0xfff0c9b4 M [] in ACTestRunnerTest(TestCase)>timeout:after: 0xad23ef0: a(n) ACTestRunnerTest 0xfff0c9d4 M BlockClosure>ensure: 0xb680530: a(n) BlockClosure 0xfff0c9fc M ACTestRunnerTest(TestCase)>timeout:after: 0xad23ef0: a(n) ACTestRunnerTest 0xfff0ca1c M [] in ACTestRunnerTest(TestCase)>runCase 0xad23ef0: a(n) ACTestRunnerTest 0xfff0ca3c M BlockClosure>ensure: 0xb680630: a(n) BlockClosure 0xfff0ca58 M ACTestRunnerTest(TestCase)>runCase 0xad23ef0: a(n) ACTestRunnerTest 0xfff0ca70 M SCISqueakTestRunner(SCITestRunner)>basicRunCase: 0xad217f0: a(n) SCISqueakTestRunner 0xfff0ca90 M [] in SCISqueakTestRunner(SCITestRunner)>runCase: 0xad217f0: a(n) SCISqueakTestRunner 0xfff0caac M BlockClosure>on:do: 0xb6806c0: a(n) BlockClosure 0xfff0cad4 M [] in SCISqueakTestRunner(SCITestRunner)>runCase: 0xad217f0: a(n) SCISqueakTestRunner 0xfff0caf0 M BlockClosure>on:do: 0xb6807e8: a(n) BlockClosure 0xfff0cb18 M [] in SCISqueakTestRunner(SCITestRunner)>runCase: 0xad217f0: a(n) SCISqueakTestRunner 0xfff0cb34 M Time class>millisecondsToRun: 0x9610b68: a(n) Time class 0xfff0cb50 M SmalltalkCI class>timeToRun: 0xab38d38: a(n) SmalltalkCI class 0xfff0cb74 M SCISqueakTestRunner(SCITestRunner)>runCase: 0xad217f0: a(n) SCISqueakTestRunner 0xfff0cb90 M ACTestRunnerTest(TestCase)>run: 0xad23ef0: a(n) ACTestRunnerTest 0xfff0cbac M [] in SCISqueakTestRunner(SCITestRunner)>runAll 0xad217f0: a(n) SCISqueakTestRunner 0xfff0cbcc M OrderedCollection>do: 0xad21b90: a(n) OrderedCollection 0xfff0cbf0 I SCISqueakTestRunner(SCITestRunner)>runAll 0xad217f0: a(n) SCISqueakTestRunner 0xfff0cc08 M [] in SCISqueakTestRunner(SCITestRunner)>run 0xad217f0: a(n) SCISqueakTestRunner 0xfff0cc2c I Time class>millisecondsToRun: 0x9610b68: a(n) Time class 0xfff0cc50 I SmalltalkCI class>timeToRun: 0xab38d38: a(n) SmalltalkCI class 0xfff0cc6c M [] in SCISqueakTestRunner(SCITestRunner)>run 0xad217f0: a(n) SCISqueakTestRunner 0xfff0cc8c M BlockClosure>ensure: 0xad21c80: a(n) BlockClosure 0xad21808 s SCISqueakTestRunner(SCITestRunner)>run 0xad3e280 s SCISqueakTestRunner class(SCITestRunner class)>runSuite:spec: 0xad218c8 s SCISqueakTestRunner class(SCITestRunner class)>runClasses:spec: 0xad3e220 s SCISqueakTestRunner class(SCITestRunner class)>runSpec: 0xb619070 s SmalltalkCISqueak(SmalltalkCI)>runTests 0xb61ec00 s [] in SmalltalkCISqueak(SmalltalkCI)>basicTest 0xb6503d0 s [] in SCISqueakCodeCoverage(SCICodeCoverage)>run: 0xb65b340 s BlockClosure>ensure: 0xad219a8 s SCISqueakCodeCoverage(SCICodeCoverage)>run: 0xad3e1c0 s SCISqueakCodeCoverage class(SCICodeCoverage class)>run:spec:in: 0xad21a08 s [] in SmalltalkCISqueak(SmalltalkCI)>basicTest 0xad3e160 s [] in SmalltalkCISqueak class(SmalltalkCI class)>fold:on:block: 0xb619010 s Time class>millisecondsToRun: 0xb61eba0 s SmalltalkCI class>timeToRun: 0xad21a80 s SmalltalkCISqueak class(SmalltalkCI class)>fold:on:block: 0xad21ae0 s SmalltalkCISqueak class(SmalltalkCI class)>fold:block: 0xad20f70 s SmalltalkCISqueak class(SmalltalkCI class)>stage:id:block: 0xad21010 s SmalltalkCISqueak(SmalltalkCI)>basicTest 0xad3e460 s [] in SmalltalkCISqueak(SmalltalkCI)>test 0xb4d1150 s BlockClosure>on:do: 0xad210b0 s [] in SmalltalkCISqueak(SmalltalkCI)>test 0xad3e400 s [] in SmalltalkCISqueak class(SmalltalkCI class)>withBuildStatusReportingDo: 0xb4d11b0 s BlockClosure>on:do: 0xad21158 s SmalltalkCISqueak class(SmalltalkCI class)>withBuildStatusReportingDo: 0xad211b8 s SmalltalkCISqueak(SmalltalkCI)>test 0xad3e3a0 s SmalltalkCI class>test:projectDirectory: 0xb619130 s SmalltalkCI class>test: 0xad21260 s UndefinedObject>DoIt 0xad213a0 s Compiler>evaluateCue:ifFail: 0xad21438 s Compiler>evaluateCue:ifFail:logged: 0xad3e340 s Compiler>evaluate:in:to:notifying:ifFail:logged: 0xad21670 s Compiler class>evaluate:for:notifying:logged: 0xad3e2e0 s Compiler class>evaluate:for:logged: 0xb6190d0 s Compiler class>evaluate:logged: 0xb61ec60 s [] in ReadStream(PositionableStream)>fileInAnnouncing: 0xb4d1210 s BlockClosure>on:do: 0xad21700 s [] in ReadStream(PositionableStream)>fileInAnnouncing: 0xad205f8 s [] in MorphicUIManager>displayProgress:at:from:to:during: 0xb4d1090 s BlockClosure>on:do: 0xad20690 s [] in MorphicUIManager>displayProgress:at:from:to:during: 0xad3e640 s BlockClosure>ensure: 0xad20728 s MorphicUIManager>displayProgress:at:from:to:during: 0xad3e5e0 s ProgressInitiationException>defaultResumeValue 0xb6192b0 s ProgressInitiationException(Exception)>resume 0xb61ede0 s ProgressInitiationException>defaultAction 0xb6504f0 s UndefinedObject>handleSignal: 0xad207d8 s ProgressInitiationException(Exception)>signal 0xad20838 s ProgressInitiationException>display:at:from:to:during: 0xad3e580 s ProgressInitiationException class>display:at:from:to:during: 0xb619250 s ByteString(String)>displayProgressAt:from:to:during: 0xb61ed80 s ByteString(String)>displayProgressFrom:to:during: 0xad208c0 s ReadStream(PositionableStream)>fileInAnnouncing: 0xad3e520 s ReadStream(PositionableStream)>fileIn 0xb6191f0 s CodeLoader>installSourceFile: 0xb61ed20 s [] in CodeLoader>installSourceFiles 0xb650490 s Array(SequenceableCollection)>do: 0xad20b80 s CodeLoader>installSourceFiles 0xad20ce8 s ProjectLauncher>startUpAfterLogin 0xad3e4c0 s ProjectLauncher>startUp 0xb619190 s [] in AutoStart class>startUp: 0xb61ecc0 s WorldState>runStepMethodsIn: 0xb650430 s PasteUpMorph>runStepMethods 0xacfbb50 s WorldState>doOneCycleNowFor: 0xacfbbb0 s WorldState>doOneCycleFor: 0xacfbc10 s PasteUpMorph>doOneCycle 0x99caec8 s [] in MorphicProject>spawnNewProcess 0x95e1050 s [] in BlockClosure>newProcess ``` The bug is also present in earlier VMVersions. Like in this build on travis: https://travis-ci.org/hpi-swa-teaching/AcceptIt/builds/389123915 This is how the log looks in those cases sometimes: ``` Segmentation fault Tue Jun 12 17:32:55 2018 /home/travis/smalltalkCI-master/_cache/vms/cogspurlinux/lib/squeak/5.0-3427/squeak Squeak VM version: 5.0-3427 Fri Aug 21 22:07:53 PDT 2015 gcc 4.4.7 [Production Spur ITHB VM] Built from: CoInterpreter VMMaker.oscog-eem.1441 uuid: c41d605b-7d2e-4ecc-95e1-b295119106a7 Aug 21 2015 With: StackToRegisterMappingCogit VMMaker.oscog-eem.1436 uuid: 9d2442c4-2066-4ffd-a215-e7e2b6cb8eed Aug 21 2015 Revision: VM: r3427 http://www.squeakvm.org/svn/squeak/branches/Cog Date: 2015-08-21 20:39:38 -0700 Plugins: r3415 http://squeakvm.org/svn/squeak/trunk/platforms/Cross/plugins Build host: Linux mclinux32 2.6.32-431.el6.i686 #1 SMP Fri Nov 22 00:26:36 UTC 2013 i686 i686 i386 GNU/Linux plugin path: /home/travis/smalltalkCI-master/_cache/vms/cogspurlinux/lib/squeak/5.0-3427 [default: /home/travis/smalltalkCI-master/_cache/vms/cogspurlinux/lib/squeak/5.0-3427/] C stack backtrace & registers: eax 0xffe105e4 ebx 0xffe10500 ecx 0xffe10598 edx 0xffe1054c edi 0xffe103d0 esi 0xffe103d0 ebp 0xffe10468 esp 0xffe104b4 eip 0xffe106c8 *[0xffe106c8] /home/travis/smalltalkCI-master/_cache/vms/cogspurlinux/lib/squeak/5.0-3427/squeak[0x805f200] /home/travis/smalltalkCI-master/_cache/vms/cogspurlinux/lib/squeak/5.0-3427/squeak[0x805f4ff] [0xf7f8dde0] /home/travis/smalltalkCI-master/_cache/vms/cogspurlinux/lib/squeak/5.0-3427/squeak[0x806d580] /home/travis/smalltalkCI-master/_cache/vms/cogspurlinux/lib/squeak/5.0-3427/squeak[0x8099817] /home/travis/smalltalkCI-master/_cache/vms/cogspurlinux/lib/squeak/5.0-3427/squeak(ceStackOverflow+0x6d)[0x809cc5d] [0x890028e] /home/travis/smalltalkCI-master/_cache/vms/cogspurlinux/lib/squeak/5.0-3427/squeak(interpret+0x86e)[0x809d50e] /home/travis/smalltalkCI-master/_cache/vms/cogspurlinux/lib/squeak/5.0-3427/squeak(main+0x2b4)[0x805fc54] /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xf7d66af3] /lib/i386-linux-gnu/libc.so.6(+0x1ad450)[0xf7efa450] Smalltalk stack dump: 0xffe7a3c4 M INVALID RECEIVER>(nil) 0x93d0a68: a(n) 0xffe7a3e4 M [] in INVALID RECEIVER>(nil) 0x8a0ffd0: a(n) 0xffe7a404 M INVALID RECEIVER>(nil) 0x8a18328: a(n) 0xffe7a420 M INVALID RECEIVER>(nil) 0x8a0ffd0: a(n) 0xffe7a444 M INVALID RECEIVER>(nil) 0x8a0ff50: a(n) 0xffe7a468 I INVALID RECEIVER>(nil) 0x8ce1a40: a(n) 0xffe7a484 M [] in INVALID RECEIVER>(nil) 0xaa40110: a(n) 0xffe7a4a0 M INVALID RECEIVER>(nil) 0x8a107f8: a(n) 0xffe7a4c0 M [] in INVALID RECEIVER>(nil) 0x8a10798: a(n) 0xffe7a4e0 M INVALID RECEIVER>(nil) 0x8ce1c00: a(n) 0xffe7a504 M INVALID RECEIVER>(nil) 0x8a10798: a(n) 0xffe7a520 M INVALID RECEIVER>(nil) 0x8ce1a40: a(n) 0xffe7a548 I INVALID RECEIVER>(nil) 0x1=0 0xffe7a560 I INVALID RECEIVER>(nil) 0xaa318c8: a(n) 0xffe7a580 M INVALID RECEIVER>(nil) 0x8a0a180: a(n) 0xffe7a5a4 M INVALID RECEIVER>(nil) 0x8a0a180: a(n) 0xffe7a5c4 M INVALID RECEIVER>(nil) 0xaa316c0: a(n) 0xffe7a5e8 M INVALID RECEIVER>(nil) 0x8a0a180: a(n) 0xffe7a608 M INVALID RECEIVER>(nil) 0x8a0a180: a(n) 0xffe7a62c M INVALID RECEIVER>(nil) 0x8a0a180: a(n) 0xffe7a65c M INVALID RECEIVER>(nil) 0x8a0a180: a(n) 0xffe7a688 M INVALID RECEIVER>(nil) 0x8a0a180: a(n) 0xffe7a6b4 M INVALID RECEIVER>(nil) 0x8a0a180: a(n) 0xffe7a6d8 M INVALID RECEIVER>(nil) 0x8a0a180: a(n) 0xffe7a700 I INVALID RECEIVER>(nil) 0xa968260: a(n) 0xffe7a720 I INVALID RECEIVER>(nil) 0xa968260: a(n) 0xffe7a73c M INVALID RECEIVER>(nil) 0xaa40110: a(n) 0xffe7a754 M INVALID RECEIVER>(nil) 0xaa40110: a(n) 0xffe7a76c M [] in INVALID RECEIVER>(nil) 0xaa40110: a(n) 0xffe7a788 M INVALID RECEIVER>(nil) 0x8a0fe30: a(n) 0xffe7a7b0 M [] in INVALID RECEIVER>(nil) 0xaa40110: a(n) 0xffe1b448 M INVALID RECEIVER>(nil) 0x8a0fcd8: a(n) 0xffe1b470 M INVALID RECEIVER>(nil) 0xaa40110: a(n) 0xffe1b490 M [] in INVALID RECEIVER>(nil) 0xaa40110: a(n) 0xffe1b4b0 M INVALID RECEIVER>(nil) 0x8a0fea8: a(n) 0xffe1b4cc M INVALID RECEIVER>(nil) 0xaa40110: a(n) 0xffe1b4e4 M INVALID RECEIVER>(nil) 0xaa397f0: a(n) 0xffe1b504 M [] in INVALID RECEIVER>(nil) 0xaa397f0: a(n) 0xffe1b520 M INVALID RECEIVER>(nil) 0x8a0ff38: a(n) 0xffe1b548 M [] in INVALID RECEIVER>(nil) 0xaa397f0: a(n) 0xffe1b564 M INVALID RECEIVER>(nil) 0x8a10060: a(n) 0xffe1b58c M [] in INVALID RECEIVER>(nil) 0xaa397f0: a(n) 0xffe1b5a8 M INVALID RECEIVER>(nil) 0x93c1ab0: a(n) 0xffe1b5c4 M INVALID RECEIVER>(nil) 0xa8de168: a(n) 0xffe1b5e8 M INVALID RECEIVER>(nil) 0xaa397f0: a(n) 0xffe1b604 M INVALID RECEIVER>(nil) 0xaa40110: a(n) 0xffe1b620 M [] in INVALID RECEIVER>(nil) 0xaa397f0: a(n) 0xffe1b640 M INVALID RECEIVER>(nil) 0xaa39900: a(n) 0xffe1b664 I INVALID RECEIVER>(nil) 0xaa397f0: a(n) 0xffe1b684 I [] in INVALID RECEIVER>(nil) 0xaa397f0: a(n) 0xffe1b6a8 I INVALID RECEIVER>(nil) 0x93c1ab0: a(n) 0xffe1b6cc I INVALID RECEIVER>(nil) 0xa8de168: a(n) 0xffe1b6f0 I [] in INVALID RECEIVER>(nil) 0xaa397f0: a(n) 0xffe1b710 M INVALID RECEIVER>(nil) 0xaa399f0: a(n) 0xffe1b734 I INVALID RECEIVER>(nil) 0xaa397f0: a(n) 0xffe1b754 I INVALID RECEIVER>(nil) 0xa9600a8: a(n) 0xffe1b784 I INVALID RECEIVER>(nil) 0xa9600a8: a(n) 0xffe1b7ac I INVALID RECEIVER>(nil) 0xa9600a8: a(n) 0xaa39bb8 is not a context Most recent primitives **StackOverflow** **StackOverflow** stack page bytes 4096 available headroom 2788 minimum unused headroom 3016 (Segmentation fault) /home/travis/smalltalkCI-master/_builds/vm: line 1: 3323 Aborted (core dumped) /home/travis/smalltalkCI-master/_cache/vms/cogspurlinux/squeak "$@" ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/267

3 4

Re: [Vm-dev] [Pharo-dev] Minheadless trial
by Ben Coman 08 Aug '18

08 Aug '18

On 7 August 2018 at 13:47, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi Ben, > > Sorry for coming here so late, I didn’t see this thread before. > I already have a working minheadless branch that was adapted to Eliot’s > process. > It was working for Pharo in Linux and Mac (Windows was ongoing but not > finished, that’s why is not pushed). > > You can find this branch here: > > https://github.com/estebanlm/opensmalltalk-vm/tree/add-minheadless-vm > I'll have a look at it. > Interesting part is that I didn’t tackled any of the issues you are > working on, so the work is easily mergeable :) > > Cheers, > Esteban > > Ps: with some changes in image, I’m using exclusively this VM since a > couple of months and it works fine. > That is good to know. So just to be clear... even though its name indicates "headless", you are running a full graphical Image? I got more curious about the original announcement saying... "minheadless is a VM variant that unifies a lot of the code for Windows, Linux and OS X." So here https://docs.google.com/spreadsheets/d/183GnSKZSMSEgVQZ0Fqa7-vITqKSpAlW_Axn… I compare... find "platforms/Win32/vm" -exec wc {} \; find "platforms/Unix/vm" -exec wc {} \; find "platforms/Mac OS/vm" -exec wc {} \; to... find "platforms/minheadless" -exec wc {} \; and if nothing important has been missed it seems about 30% of the original size. I'd expect Ronie's effort to produce this should have a massive impact on future maintainability. cheers -ben P.S. I excluded the following presuming its common before/after. find "platforms/Cross/vm" -exec wc {} \; btw, its about half the size of platforms/minheadless.

1 0

[ANN] 201807260206 now used by smalltalkCI across all Squeak builds
by Fabio Niephaus 04 Aug '18

04 Aug '18

Hi all, OpenSmalltalkVM 201807260206 [1] appears to be working very well across all major platforms, so I've decided to finally upgrade the VMs used by smalltalkCI [2]. If, for some reason, your Travis, AppVeyor, or GitLab CI builds are failing because of this, please open an issue at [3]. Happy testing, Fabio [1] https://github.com/OpenSmalltalk/opensmalltalk-vm/releases/tag/201807260206 [2] https://github.com/hpi-swa/smalltalkCI [3] https://github.com/hpi-swa/smalltalkCI/issues/new

1 0

in-line method lookup caching of booleans
by Ben Coman 04 Aug '18

04 Aug '18

Just a brain twitch about something I'd like to understand better... At http://www.mirandabanda.org/cogblog/2011/03/01/build-me-a-jit-as-fast-as-yo… it says... "[Monomorphic] inline caching depends on the fact that in most programs at most send sites there is no polymorphism and that most sends bind to *exactly_one* class of receiver over some usefully long period of time. ... In Cog we implement inline caches in three forms ... monomorphic inline cache ... closed polymorphic inline cache ... open polymorphic cache. What’s nice is that while these sends are increasingly expensive moving from monomorphic to megamorphic they are also decreasingly common in roughly a 90%, 9% 0.9% ratio, at least for typical Smalltalk programs" First, I'm curious what is the relative performance of the three different caches ? Second, I'm curious how Booleans are dealt with. Boolean handling must be fairly common, and at the Image level these are two different classes, which pushes out of the monomorphic inline cache, which may be a significant impact on performance. I started wondering if under the hood the VM could treat the two booleans as one class and in the instance store "which-boolean" it actually is. Then for example the #ifTrue:ifFalse: method of each class would be compiled into a single method conditioned at the start on "which-boolean" as to which path is executed. How feasible would that be, and would it make much of a difference in performance of booleans ? Except then I realized that this situation is already bypassed by common boolean methods being inlined by the compiler. Still curious, if there are quick answers to my questions. cheers -ben

3 7

Nike Air Lunar generate the latest silhouette
by kjdshfkjsa 03 Aug '18

03 Aug '18

woodie Nike Trainers <http://www.trainersrunner.co.uk/> white (oyster holdings resourceful director) provides us all a great on-feet evaluate the particular future oyster holdings by adidas twinstrike adv effort. this particular unique iteration belonging to the adidas twinstrike adv will come dressed within a white wine mesh along with house higher contrasted through the glowing blue, crimson, yellowish plus green bites known on the slightly designed rubberized outsole. different particularly the actual sneaker are the skeleton-like lacing system plus the slightly intended language together with trefoil personalisation on the item. no phrase with if these might be falling, however hunt for statement to become built soon. nike shoes for men <http://www.sportsfaith.co.uk/> menswear custom mark elliott has eventually consumed time to help technically bring out his or her newest effort that can end up being with none besides lebron david. according to elliott, the gathering is a undertaking in which she has also been implementing for just two decades now but it lastly see it is full price discharge that weekend. the gathering is actually reminded through the all-new bill elliott back button nike lebron image that calls for dna via the nike lebron 8 as well as purposes this to set-up a brand new silhouette. the gathering will also include apparel to match this trainers. in the store amount with the kicks will be $250. formerly Cheap Nike Shoes <http://www.trainersrunner.co.uk/> likely to discharge these days (august 1st) there are actually new reports which have presented the particular nike weather a lot more uptempo hoyas a strong up to date relieve time. this nike air more uptempo starts which has a nice greyish leather-based higher together with perforations found for the edge cells. the actual signature bank more substantial compared to your life "air" logos around the edge solar panels is complete around night time navy insurance policy coverage laces are generally quit whitened to accomplish your georgetown hoyas idea. often be searching for the nike weather much more uptempo hoyas for you to right now discharge on august 30th for the price tag involving $160. nike outlet <http://www.sportsfaith.co.uk/> can be switching issues upwards within a major manner with this different colorway connected with the nike air max 270. called a new payment new release, that substantiation is within that pudding as soon as you obtain 1st check out this air max 270. differentiating itself from your classic mesh as well as flyknit choices, this air max 270 includes a great all-new perforated house around the bottom that has a tumbled/pebbled household leather obtaining for the heel/ankle area. added textures comprise mesh and also nubuck that will get along with the actual quality appear. as long as colorations go, the sneaker occurs carried out around stringed advertising wasteland ochre for the upper along with olive describing around the logos. -- Sent from: http://forum.world.st/Squeak-VM-f104410.html

1 0

Re: [Vm-dev] PICs (was: RISC-V J Extension)
by Jecel Assumpcao Jr. 01 Aug '18

01 Aug '18

While it is bad form to move a private discussion to (or back to) a public forum, some of these links might be interesting to people here and I have been unable to send emails to Tobias after my initial reply. An attempt on Wednesday and on Friday made mcrelay.correio.biz complain that mx00.emig.gmx.net[ refused to talk to it and an attempt from my old 1991 email account on Monday complained about the email address though it was ok as far as I can tell. Tobias wrote: > Jecel wrote: > > [new direction: emulate bytecodes and RISC-V] > > That'a an interesting take. > > I can only watch from afar, but its all interesting. (for example that guy > who does RISC-V cpu in TTL chips: https://www.youtube.com/channel/UCBcljXmuXPok9kT_VGA3adg ) It is an interesting project. I was annoyed by his claim to have the first homebrew TTL 32 bit processor since in the late 1990s a group of students at the MIT processor design course implemented the Beta processor in TTLs instead of using FPGAs like all other groups (before or since). Sadly, all information about this has been eliminated from the web and can't even be found in archive.org. I tried to get the local universities to teach RISC-V to their students instead of their own educational RISC processors but they are too emotionally attached to their designs. > Sounds reasonable. Let's have them know dynamic languages are also still there ;) > (I mean, you're very familiar with both Smalltalk and Self...) Mario Wolczko has been involved in Java since the late 1990s but was part of the Self group before that and had created the Mushroom Smalltalk computer before that. http://www.wolczko.com/ Boris Shingarov is currently involved with Java but has given a lot of talk about Smalltalk VMs and was involved in Squeak back in the OS/2 days. http://shingarov.com/ With me, that was 3 out of 6 people at the meeting representing the Smalltalk viewpoint. We shall see if that will have any practical effect. > The TLB is somewhat maintained by the CPU to manage the translation of virtual addresses to physical ones. > > I can imagine something similar, like a branch, that upon return, updates a filed > in a PIC buffer, such that the next time the branch is only taken if a register (eg, class of the object) > is different or so. Ok, Mario actually mentioned that with today's advanced branch prediction hardware we might want to re-evaluate PICs. In this case you wouldn't be using the TLBs but the BTB (Branch Target Buffer) hardware. https://www.slideshare.net/lerruby/like-2014214 Mario might have actually been thinking about Urs Hölzle's ECOOP 95 paper, which was a slightly different subject. http://hoelzle.org/publications/ecoop95-dispatch.pdf They were looking at the different kinds of software implementation of method dispatch (not only PICs) and the effects of processors executing more and more instructions per clock cycle. That might make a scheme that is bad for a simple RISC (due to many tests, for example) actually work well on an advanced out-of-order processor (due to the test being "free" since they execute in parallel with the main code). They didn't look at branch prediction hardware, but it certainly would have a huge impact. Several of the later papers focused on branch prediction: http://hoelzle.org/publications.html > > For SiliconSqueak I actually had two different PIC instructions. They > > modified how the instruction cache works. Normally the instruction cache > > is accessed by hashing the 32 bit value of the PC except for the lowest > > bits which select a byte in the cache line, but after a PIC instruction > > the hash used a 64 bit value that combined the PC (all bits) and the > > pointer to the receiver's class. The resulting cache line was fetched > > and instructions executed in sequence even though the PC didn't change. > > Any branch or call instruction would restart normal execution at the new > > PC. > > Sounds neat! > > > So a PIC entry takes up exactly one cache line. A PIC can have as many > > entries as needed and the instruction takes the same time to execute no > > matter how many entries there are (not taking into account cache > > misses). > > Wow thats incredible. > > > The second PIC instruction works exactly like the first but it supplies > > a different value to be used in place of the current PC. That allows > > different call sites to share PIC entries if needed, though that might > > be more complicated than it is worth. > > Maybe. What I like about PICs per send site is that you can essentially use them > as data source for dynamic feedback (what "types" where actually seen at this send site?) > and one probably would need some instructions to fetch those infos from the PIC. One of the papers in that list is the 1997 techical report "The Space Overhead of Customization". One of the reasons that Java won over Self was that its simple interpreter ran on 8MB machines that most of Sun's customers had while Self needed 24MB workstations which were rare (but would be very common just two years later). Part of that was due to compiling a new version of native code for every different type of receiver even if the different versions didn't really help. My idea of allowing PICs to be optionally shared was that this would allow customization to be limited in certain cases to save memory. It would cause a loss of information about types seen at a call site, but that doesn't always have a great impact on performance. -- Jecel

7 11

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Vm-dev August 2018