Hi.
I tested latest vm on raspberry
squeak -headless Squeak6.0alpha-16548-32bit.image
it crashed with attached dump with message:
stack page bytes 4096 available headroom 2788 minimum unused headroom 3520
(Segmentation fault)
Details on OS: Linux raspberrypi 3.12.28+ #709 PREEMPT Mon Sep 8 15:28:00 BST 2014 armv6l GNU/Linux
I have also some old VM which is working fine: CoInterpreter * VMMaker.oscog-eem.2107 uuid: 19c0fa53-acc2-40f9-9a07-17510e614ae5 Jan 23 2017 StackToRegisterMappingCogit * VMMaker.oscog-eem.2107 uuid: 19c0fa53-acc2-40f9-9a07-17510e614ae5 Jan 23 2017 VM: 201701231021 https://github.com/pharo-project/pharo-vm.git $ Date: Mon Jan 23 11:21:48 2017 +0100 $ Plugins: 201701231021 https://github.com/pharo-project/pharo-vm.git $
Would be nice to get it fixed for upcoming Pharo releaze.
Best regards, Denis
On 25-04-2017, at 10:38 AM, Denis Kudriashov dionisiydk@gmail.com wrote:
Details on OS: Linux raspberrypi 3.12.28+ #709 PREEMPT Mon Sep 8 15:28:00 BST 2014 armv6l GNU/Linux
For starters you need to update that OS. That’s over two years out of date!
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: LD: Lose Device
Seems a similar message for a variety of causes...
http://forum.world.st/Loading-an-image-crashes-the-VM-td4884470.html
http://forum.world.st/new-Cog-VMs-available-td4668103.html#a4668126
http://forum.world.st/breaking-infinite-loop-from-saved-image-td4832548.html
http://forum.world.st/VM-crash-on-update-td4943627.html
http://forum.world.st/Crash-in-Objective-C-autorelease-pool-management-for-e...
What result with latest VM? http://files.pharo.org/vm/pharo-spur32/linux/armv6/
and of course latest OS per tim's advice.
btw, just to check... ARM6 is The Rpi right?
cheer -ben
On Wed, Apr 26, 2017 at 1:38 AM, Denis Kudriashov dionisiydk@gmail.com wrote:
Hi.
I tested latest vm on raspberry
squeak -headless Squeak6.0alpha-16548-32bit.image
it crashed with attached dump with message:
stack page bytes 4096 available headroom 2788 minimum unused headroom 3520
(Segmentation fault)
Details on OS: Linux raspberrypi 3.12.28+ #709 PREEMPT Mon Sep 8 15:28:00 BST 2014 armv6l GNU/Linux
I have also some old VM which is working fine: CoInterpreter * VMMaker.oscog-eem.2107 uuid: 19c0fa53-acc2-40f9-9a07-17510e614ae5 Jan 23 2017 StackToRegisterMappingCogit * VMMaker.oscog-eem.2107 uuid: 19c0fa53-acc2-40f9-9a07-17510e614ae5 Jan 23 2017 VM: 201701231021 https://github.com/pharo-project/pharo-vm.git $ Date: Mon Jan 23 11:21:48 2017 +0100 $ Plugins: 201701231021 https://github.com/pharo-project/pharo-vm.git $
Would be nice to get it fixed for upcoming Pharo releaze.
Best regards, Denis
On 26-04-2017, at 6:49 AM, Ben Coman btc@openinworld.com wrote:
btw, just to check... ARM6 is The Rpi right?
Yup. Although strictly speaking something over 80% of all Pi are v7 cpus the ‘rule’ is to compile v6 to avoid complicated multiple executables. Given that the vm isn’t actually all that big I’d say we could get away with it if we really wanted but so far I’ve not heard any evidence of a major performance difference.
The change I really want to make is going for the AArch64 target. It wouldn’t make a giant difference on a current Pi (maybe 20%) but it would open up the coming world of 64bit ARM OSs with 3+GHz 48-core CPUs and so on. All I need is
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Don't document the program; program the document.
Now I found last working VM:
CoInterpreter VMMaker.oscog-eem.2134 uuid: 4721ad0c-159c-4bf2-9f3e-c9917fcdead5 Feb 27 2017
StackToRegisterMappingCogit VMMaker.oscog-eem.2134 uuid: 4721ad0c-159c-4bf2-9f3e-c9917fcdead5 Feb 27 2017
VM: 201702270943 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Mon Feb 27 10:43:22 2017 +0100 $ Plugins: 201702270943 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Also I checked that latest stackVM is working. And I attach newest crash.dmp for today spur vm
2017-04-26 19:15 GMT+02:00 tim Rowledge tim@rowledge.org:
On 26-04-2017, at 6:49 AM, Ben Coman btc@openinworld.com wrote:
btw, just to check... ARM6 is The Rpi right?
Yup. Although strictly speaking something over 80% of all Pi are v7 cpus the ‘rule’ is to compile v6 to avoid complicated multiple executables. Given that the vm isn’t actually all that big I’d say we could get away with it if we really wanted but so far I’ve not heard any evidence of a major performance difference.
The change I really want to make is going for the AArch64 target. It wouldn’t make a giant difference on a current Pi (maybe 20%) but it would open up the coming world of 64bit ARM OSs with 3+GHz 48-core CPUs and so on. All I need is
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Don't document the program; program the document.
2017-04-26 15:49 GMT+02:00 Ben Coman btc@openinworld.com:
What result with latest VM? http://files.pharo.org/vm/pharo-spur32/linux/armv6/
With Pharo result the same. It crashed
On 25-04-2017, at 10:38 AM, Denis Kudriashov dionisiydk@gmail.com wrote:
Hi.
I tested latest vm on raspberry squeak -headless Squeak6.0alpha-16548-32bit.image
it crashed with attached dump with message: stack page bytes 4096 available headroom 2788 minimum unused headroom 3520
I can now confirm seeing this on my Pi systems, using a built-from-yesterday code. Guess we have some tracking down to do.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RCR: Rewind Card Reader
I had several crash dump on MacOS too, but rather random (only the end of file joined might be relevant) crash.dmp https://drive.google.com/file/d/0BwrD2q9lZVJ1QWlsNTBnaTFadlU/view?usp=drive_web
2017-04-28 21:03 GMT+02:00 tim Rowledge tim@rowledge.org:
On 25-04-2017, at 10:38 AM, Denis Kudriashov dionisiydk@gmail.com
wrote:
Hi.
I tested latest vm on raspberry squeak -headless Squeak6.0alpha-16548-32bit.image
it crashed with attached dump with message: stack page bytes 4096 available headroom 2788 minimum unused headroom
3520
I can now confirm seeing this on my Pi systems, using a built-from-yesterday code. Guess we have some tracking down to do.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: RCR: Rewind Card Reader
I managed to find a 2017-01-28 ARM vm (by accident, on https://github.com/OpenSmalltalk/opensmalltalk-vm/releases after hitting the ‘Releases’ button) and that appears to run OK. So at least we don’t have to go all the way back to 5.1 …
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim In computer science, we stand on each other's feet.
On 28-04-2017, at 3:34 PM, tim Rowledge tim@rowledge.org wrote:
I managed to find a 2017-01-28 ARM vm (by accident, on https://github.com/OpenSmalltalk/opensmalltalk-vm/releases after hitting the ‘Releases’ button) and that appears to run OK. So at least we don’t have to go all the way back to 5.1 …
And after finally finding a pointer to this bintray thing I can reasonably certainly claim that the break is somewhere between the 20170227 and 20170327 versions.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Fractured Idiom:- VISA LA FRANCE - Don't leave chateau without it
2017-04-29 21:18 GMT+02:00 tim Rowledge tim@rowledge.org:
I managed to find a 2017-01-28 ARM vm (by accident, on
https://github.com/OpenSmalltalk/opensmalltalk-vm/releases after hitting the ‘Releases’ button)
and that appears to run OK. So at least we don’t have to go all the way
back to 5.1 …
And after finally finding a pointer to this bintray thing I can reasonably certainly claim that the break is somewhere between the 20170227 and 20170327 versions.
Tim, you are probably skipped my mail:
Now I found last working VM:
CoInterpreter VMMaker.oscog-eem.2134 uuid: 4721ad0c-159c-4bf2-9f3e-c9917fcdead5 Feb 27 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2134 uuid: 4721ad0c-159c-4bf2-9f3e-c9917fcdead5 Feb 27 2017 VM: *201702270943* https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Mon Feb 27 10:43:22 2017 +0100 $ Plugins: 201702270943 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
(I already checked bintray binaries)
On 29-04-2017, at 12:26 PM, Denis Kudriashov dionisiydk@gmail.com wrote:
2017-04-29 21:18 GMT+02:00 tim Rowledge tim@rowledge.org:
I managed to find a 2017-01-28 ARM vm (by accident, on https://github.com/OpenSmalltalk/opensmalltalk-vm/releases after hitting the ‘Releases’ button) and that appears to run OK. So at least we don’t have to go all the way back to 5.1 …
And after finally finding a pointer to this bintray thing I can reasonably certainly claim that the break is somewhere between the 20170227 and 20170327 versions.
Tim, you are probably skipped my mail:
Now I found last working VM: CoInterpreter VMMaker.oscog-eem.2134 uuid: 4721ad0c-159c-4bf2-9f3e-c9917fcdead5 Feb 27 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2134 uuid: 4721ad0c-159c-4bf2-9f3e-c9917fcdead5 Feb 27 2017 VM: 201702270943 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Mon Feb 27 10:43:22 2017 +0100 $ Plugins: 201702270943 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
(I already checked bintray binaries)
Ah, I think it more likely that I simply didn’t properly see the date in there. And it’s good to get replication of data too; it makes it less likely that we are hallucinating :-)
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- One sandwich short of a picnic.
Just to complete the story (hopefully) the latest (as of may 5th 2017) generated code seems to run perfectly well on my Pi. AIUI the proximate cause of the problem was a missed saving of the link register in the new has primitive code.
On 29-04-2017, at 12:28 PM, tim Rowledge tim@rowledge.org wrote:
On 29-04-2017, at 12:26 PM, Denis Kudriashov dionisiydk@gmail.com wrote:
2017-04-29 21:18 GMT+02:00 tim Rowledge tim@rowledge.org:
I managed to find a 2017-01-28 ARM vm (by accident, on https://github.com/OpenSmalltalk/opensmalltalk-vm/releases after hitting the ‘Releases’ button) and that appears to run OK. So at least we don’t have to go all the way back to 5.1 …
And after finally finding a pointer to this bintray thing I can reasonably certainly claim that the break is somewhere between the 20170227 and 20170327 versions.
Tim, you are probably skipped my mail:
Now I found last working VM: CoInterpreter VMMaker.oscog-eem.2134 uuid: 4721ad0c-159c-4bf2-9f3e-c9917fcdead5 Feb 27 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2134 uuid: 4721ad0c-159c-4bf2-9f3e-c9917fcdead5 Feb 27 2017 VM: 201702270943 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Mon Feb 27 10:43:22 2017 +0100 $ Plugins: 201702270943 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
(I already checked bintray binaries)
Ah, I think it more likely that I simply didn’t properly see the date in there. And it’s good to get replication of data too; it makes it less likely that we are hallucinating :-)
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- One sandwich short of a picnic.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: LJD: Lock Job on Disk
So Eliot thank you very much.
I just checked: it works perfectly
2017-05-08 3:15 GMT+02:00 tim Rowledge tim@rowledge.org:
Just to complete the story (hopefully) the latest (as of may 5th 2017) generated code seems to run perfectly well on my Pi. AIUI the proximate cause of the problem was a missed saving of the link register in the new has primitive code.
On 29-04-2017, at 12:28 PM, tim Rowledge tim@rowledge.org wrote:
On 29-04-2017, at 12:26 PM, Denis Kudriashov dionisiydk@gmail.com
wrote:
2017-04-29 21:18 GMT+02:00 tim Rowledge tim@rowledge.org:
I managed to find a 2017-01-28 ARM vm (by accident, on
https://github.com/OpenSmalltalk/opensmalltalk-vm/releases after hitting the ‘Releases’ button)
and that appears to run OK. So at least we don’t have to go all the
way back to 5.1 …
And after finally finding a pointer to this bintray thing I can
reasonably certainly claim that the break is somewhere between the 20170227 and 20170327 versions.
Tim, you are probably skipped my mail:
Now I found last working VM: CoInterpreter VMMaker.oscog-eem.2134 uuid: 4721ad0c-159c-4bf2-9f3e-c9917fcdead5
Feb 27 2017
StackToRegisterMappingCogit VMMaker.oscog-eem.2134 uuid:
4721ad0c-159c-4bf2-9f3e-c9917fcdead5 Feb 27 2017
VM: 201702270943 https://github.com/OpenSmalltalk/opensmalltalk-vm.git
$ Date: Mon Feb 27 10:43:22 2017 +0100 $ Plugins: 201702270943 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
(I already checked bintray binaries)
Ah, I think it more likely that I simply didn’t properly see the date in
there. And it’s good to get replication of data too; it makes it less likely that we are hallucinating :-)
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- One sandwich short of a picnic.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: LJD: Lock Job on Disk
Hi Denis,
On May 10, 2017, at 6:32 AM, Denis Kudriashov dionisiydk@gmail.com wrote:
So Eliot thank you very much.
I just checked: it works perfectly
you're welcome! Sorry for breaking it.
2017-05-08 3:15 GMT+02:00 tim Rowledge tim@rowledge.org:
Just to complete the story (hopefully) the latest (as of may 5th 2017) generated code seems to run perfectly well on my Pi. AIUI the proximate cause of the problem was a missed saving of the link register in the new has primitive code.
On 29-04-2017, at 12:28 PM, tim Rowledge tim@rowledge.org wrote:
On 29-04-2017, at 12:26 PM, Denis Kudriashov dionisiydk@gmail.com wrote:
2017-04-29 21:18 GMT+02:00 tim Rowledge tim@rowledge.org:
I managed to find a 2017-01-28 ARM vm (by accident, on https://github.com/OpenSmalltalk/opensmalltalk-vm/releases after hitting the ‘Releases’ button) and that appears to run OK. So at least we don’t have to go all the way back to 5.1 …
And after finally finding a pointer to this bintray thing I can reasonably certainly claim that the break is somewhere between the 20170227 and 20170327 versions.
Tim, you are probably skipped my mail:
Now I found last working VM: CoInterpreter VMMaker.oscog-eem.2134 uuid: 4721ad0c-159c-4bf2-9f3e-c9917fcdead5 Feb 27 2017 StackToRegisterMappingCogit VMMaker.oscog-eem.2134 uuid: 4721ad0c-159c-4bf2-9f3e-c9917fcdead5 Feb 27 2017 VM: 201702270943 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Mon Feb 27 10:43:22 2017 +0100 $ Plugins: 201702270943 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
(I already checked bintray binaries)
Ah, I think it more likely that I simply didn’t properly see the date in there. And it’s good to get replication of data too; it makes it less likely that we are hallucinating :-)
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- One sandwich short of a picnic.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: LJD: Lock Job on Disk
vm-dev@lists.squeakfoundation.org