Hi Eliot,
On 19 January 2018 at 23:04, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Alistair, Hi Clément,
On Fri, Jan 19, 2018 at 12:53 PM, Alistair Grant akgrant0710@gmail.com wrote:
Hi Clément,
On 19 January 2018 at 17:21, Alistair Grant akgrant0710@gmail.com wrote:
Hi Clément,
On 19 January 2018 at 17:04, Clément Bera bera.clement@gmail.com wrote:
Does not seem to be related to prim 105.
I suspect that the problem is the same compactor bug I've been trying to reproduce all week, and have just fixed. Could you try and reproduce with a VM built from the latest commit?
Happy to, but I'm out all day today, so it will be tomorrow or Monday.
Cheers, Alistair (on the run...)
Some details: The SpurPlanningCompactor works by using the fact that all Spur objects have room for a forwarding pointer. The compactor make three passes:
- the first pass through memory works out where objects will go, replacig
their first fields with where they will go, and saving their first fields in a buffer (savedFirstFieldsSpace).
- the second pass scans all pointer objects, replacing their fields with
where the objects referenced will go (following the forwarding pointers), and also relocates any pointer fields in savedFirstFieldsSpace
- the final pass slides objects down, restoring their relocated first fields
The buffer used for savedFirstFieldsSpace determines how many passes are used. The system will either use eden (which is empty when compaction occurs) or a large free chunk or allocate a new segment, depending on whatever yields the largest space. So in the right circumstances eden will be used and more than one pass required.
The bug was that when multiple passes are used the compactor forgot to unmark the corpse left behind when the object was moved. Instead of the corpse being changed into free space it was retained, but its first field would be that of the forwarding pointer to its new location, not the actual first field. So on 32-bits a ByteArray that should have been collected would have its first 4 bytes appear to be invalid, and on 64-bits its first 8 bytes. Because the heap on 64-bits can grow larger it could be that the bug shows itself much less frequently than on 32-bits. When compaction can be completed in a single pass all corpses are correctly collected, so most of the time the bug is hidden.
This is the commit: commit 0fe1e1ea108e53501a0e728736048062c83a66ce Author: Eliot Miranda eliot.miranda@gmail.com Date: Fri Jan 19 13:17:57 2018 -0800
CogVM source as per VMMaker.oscog-eem.2320 Spur: Fix a bad bug in SpurPlnningCompactor.unmarkObjectsFromFirstFreeObject, used when the compactor requires more than one pass due to insufficient savedFirstFieldsSpace, expects the corpse of a moved object to be unmarked, but copyAndUnmarkObject:to:bytes:firstField: only unmarked the target. Unmarking the corpse before the copy unmarks both. This fixes a crash with ReleaseBuilder class>>saveAsNewRelease when non-use of cacheDuring: creates lots of files, enough to push the system into the multi-pass regime.
HTH, Alistair
Cheers, Alistair
On Thu, Jan 18, 2018 at 7:12 PM, Clément Bera bera.clement@gmail.com wrote:
I would suspect a bug in primitive 105 on byte objects (it was changed recently in the VM), called by copyFrom: 1 to: readCount. The bug would likely by due to specific alignment in readCount or something like that. (Assuming you're in 32 bits since the 4 bytes are corrupted).
When I get better I can have a look (I am currently quite sick).
On Thu, Jan 18, 2018 at 4:51 PM, Thierry Goubier thierry.goubier@gmail.com wrote:
Hi Cyril,
try with the last vms available at:
https://bintray.com/opensmalltalk/vm/cog/
For example, the last Ubuntu 64bits vm is at:
https://bintray.com/opensmalltalk/vm/cog/201801170946#files
Regards,
Thierry
2018-01-18 16:42 GMT+01:00 Cyrille Delaunay cy.delaunay@gmail.com: > > Hi everyone, > > I just added a new bug entry for an issue we are experimenting since > some times: > > > > https://pharo.fogbugz.com/f/cases/20982/Random-corrupted-data-when-copying-f... > > Here is the description: > > > History: > > This issue has been spotted after experimenting strange behavior > with > seaside upload. > After uploading a big file from a web browser, the modeled file > generated within pharo image begins with 4 unexpected bytes. > This issue occurs randomly: sometimes the first 4 bytes are right. > Sometimes the first 4 bytes are wrong. > This issue only occurs with Pharo 6. > This issue occurs for all platforms (Mac, Ubuntu, Windows) > > Steps to reproduce: > > I have been able to set up a small scenario that highlight the > issue. > > Download Pharo 6.1 on my Mac (Sierra 10.12.6): > https://pharo.org/web/download > Then, iterate over this process till spotting the issue: > > => start the pharo image > => execute this piece of code in a playground > > 1: > 2: > 3: > 4: > 5: > 6: > > ZnServer startDefaultOn: 1701. > ZnServer default maximumEntitySize: 80* 1024 * 1024. > '/Users/cdelaunay/myzip.zip' asFileReference writeStreamDo: [ :out | > out binary; nextPutAll: #[80 75 3 4 10 0 0 0 0 0 125 83 67 73 0 0 0 > 0 0 > 0]. > 18202065 timesRepeat: [ out nextPut: 0 ] > ]. > > => Open a web browser page on: http://localhost:1701/form-test-3 > => Upload the file zip file previously generated ('myzip.zip'). > => If the web page displays: "contents=000000000a00..." (or anything > unexpected), THIS IS THE ISSUE ! > => If the web page displays: "contents=504b03040a00..", the upload > worked fine. You can close the image (without saving) > > > > Debugging: > > > > Bob Arning has been able to reproduce the issue with my scenario. > He dived into the code involved during this process, till reaching > some > "basic" methods where he saw the issue occuring. > > Here are the conclusion till there: > => A corruption occurs while reading an input stream with method > ZnUtils > class>>readUpToEnd:limit: > The first 4 bytes may be altered randomely. > => The first 4 bytes are initially correctly written to an > outputStream. > But, the first 4 bytes of this outputStream gets altered > (corrupted), > sometimes when the inner byte array grows OR when performing the > final > "outputStream contents" > => Here is a piece of code that reproduce the issue (still > randomely. > stopping an restarting the image may change the behavior) > > 1: > 2: > 3: > 4: > 5: > 6: > 7: > 8: > 9: > 10: > 11: > 12: > 13: > 14: > 15: > 16: > 17: > 18: > 19: > 20: > > test4"self test4" | species bufferSize buffer totalRead > outputStream > answer inputStream ba byte1 | ba := ByteArray new: > 18202085. > ba atAllPut: 99. 1 to: 20 do: [ :i | ba at: i put: (#[80 75 > 3 4 10 7 > 7 7 7 7 125 83 67 73 7 7 7 7 7 7] at: i) ]. inputStream := ba > readStream. > bufferSize := 16384. species := ByteArray. > buffer := species new: bufferSize. > totalRead := 0. > outputStream := nil. > [ inputStream atEnd ] whileFalse: [ | readCount | > readCount := inputStream readInto: buffer startingAt: 1 > count: > bufferSize. > totalRead = 0 ifTrue: [ > byte1 := buffer first. > ]. > totalRead := totalRead + readCount. > > outputStream ifNil: [ > inputStream atEnd > ifTrue: [ ^ buffer copyFrom: 1 to: readCount ] > ifFalse: [ outputStream := (species new: bufferSize) > writeStream ] ]. > outputStream next: readCount putAll: buffer startingAt: 1. > byte1 = outputStream contents first ifFalse: [ self halt ]. > ]. > answer := outputStream ifNil: [ species new ] ifNotNil: [ > outputStream contents ]. > byte1 = answer first ifFalse: [ self halt ]. ^answer > > > > suspicions > > This issue appeared with Pharo 6. > > Some people suggested that it could be a vm issue, and to try my > little > scenario with the last available vm. > > I am not sure where to find the last available vm. > > I did the test using these elements: > > https://files.pharo.org/image/60/latest.zip > > https://files.pharo.org/get-files/70/pharo-mac-latest.zip/ > > > > The issue is still present > > > > > -- > Cyrille Delaunay
-- Clément Béra Pharo consortium engineer https://clementbera.wordpress.com/ Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
-- Clément Béra Pharo consortium engineer https://clementbera.wordpress.com/ Bâtiment B 40, avenue Halley 59650 Villeneuve d'Ascq
-- _,,,^..^,,,_ best, Eliot
Hi Eliot,
On Sat, Jan 20, 2018 at 09:19:04AM +0100, Alistair Grant wrote:
Hi Eliot,
On 19 January 2018 at 23:04, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Alistair, Hi Cl??ment,
On Fri, Jan 19, 2018 at 12:53 PM, Alistair Grant akgrant0710@gmail.com wrote:
Hi Cl??ment,
On 19 January 2018 at 17:21, Alistair Grant akgrant0710@gmail.com wrote:
Hi Cl??ment,
On 19 January 2018 at 17:04, Cl??ment Bera bera.clement@gmail.com wrote:
Does not seem to be related to prim 105.
I suspect that the problem is the same compactor bug I've been trying to reproduce all week, and have just fixed. Could you try and reproduce with a VM built from the latest commit?
Happy to, but I'm out all day today, so it will be tomorrow or Monday.
Cheers, Alistair (on the run...)
I've tested this with 2 images and 3 VMs in all 6 combinations:
- "Old VM": commit date: Wed Jan 10 23:39:30 2018 -0800, gcc 4.8.5 - "New VM": commit date: Sat Jan 20 13:52:26 2018 +0100, gcc 4.8.5 - "GCC 5 VM": commit date: Sat Jan 20 13:52:26 2018 +0100, gcc 5.4.0 - Clean image: commit id: b28d466f - Work image: commit id: eb0a6fb1
The gcc 5 is only there because I was playing with it. The results may be useful, or completely misleading. :-)
Each time I ran "5 timesRepeat: [ self test4 ]" with the halts replaced with a count increment. test4 is the method provided in Cyrille's original message.
Result summary:
- Old VM + Work image: 5, 5, 5, 0, 0 - Old VM + Clean image: 5, 5, 0, 0, 0 - New VM + Work image: 5, 0, 5, 5, 5 - New VM + Clean image: 0, 0, 1, 5, 5 - GCC 5 + Work image: 0, 0, 0, 0, 0 - GCC 5 + Clean image: 0, 0, 0, 0, 0
Old VM: 5.0-201801110739 Thursday 11 January 09:30:12 CET 2018 gcc 4.8.5 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2302 uuid: 55ec8f63-cdbe-4e79-8f22-48fdea585b88 Jan 11 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2302 uuid: 55ec8f63-cdbe-4e79-8f22-48fdea585b88 Jan 11 2018 VM: 201801110739 alistair@alistair-xps13:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Date: Wed Jan 10 23:39:30 2018 -0800 $ Plugins: 201801110739 alistair@alistair-xps13:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Linux b07d7880072c 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 22:00:44 UTC 2018 i686 i686 i686 GNU/Linux plugin path: /snap/pharo7/x1/usr/bin/pharo-vm32/ [default: /snap/pharo7/x1/usr/bin/pharo-vm32/]
New VM: 5.0-201801201252 Saturday 20 January 21:24:16 CET 2018 gcc 4.8.5 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2320 uuid: e2692e35-5fc8-4623-95d0-b445b3329f75 Jan 20 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2320 uuid: e2692e35-5fc8-4623-95d0-b445b3329f75 Jan 20 2018 VM: 201801201252 alistair@d62ce50f4930:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Date: Sat Jan 20 13:52:26 2018 +0100 $ Plugins: 201801201252 alistair@d62ce50f4930:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Linux 73cbbaa49451 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 22:00:44 UTC 2018 i686 i686 i686 GNU/Linux plugin path: /snap/pharo7/x1/usr/bin/pharo-vm32/ [default: /snap/pharo7/x1/usr/bin/pharo-vm32/]
GCC 5 VM: 5.0-201801201252 Sun Jan 21 14:41:41 UTC 2018 gcc 5.4.0 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2320 uuid: e2692e35-5fc8-4623-95d0-b445b3329f75 Jan 21 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2320 uuid: e2692e35-5fc8-4623-95d0-b445b3329f75 Jan 21 2018 VM: 201801201252 alistair@alistair-xps13:squeak/opensmalltalk-vm $ Date: Sat Jan 20 13:52:26 2018 +0100 $ Plugins: 201801201252 alistair@alistair-xps13:squeak/opensmalltalk-vm $ Linux ec9d95d2105a 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 22:00:44 UTC 2018 i686 i686 i686 GNU/Linux plugin path: /home/alistair/squeak/opensmalltalk-vm/products/phcogspurlinuxht/lib/pharo/5.0-201801201252 [default: /home/alistair/squeak/opensmalltalk-vm/products/phcogspurlinuxht/lib/pharo/5.0-201801201252/]
HTH, Alistair
Some details: The SpurPlanningCompactor works by using the fact that all Spur objects have room for a forwarding pointer. The compactor make three passes:
- the first pass through memory works out where objects will go, replacig
their first fields with where they will go, and saving their first fields in a buffer (savedFirstFieldsSpace).
- the second pass scans all pointer objects, replacing their fields with
where the objects referenced will go (following the forwarding pointers), and also relocates any pointer fields in savedFirstFieldsSpace
- the final pass slides objects down, restoring their relocated first fields
The buffer used for savedFirstFieldsSpace determines how many passes are used. The system will either use eden (which is empty when compaction occurs) or a large free chunk or allocate a new segment, depending on whatever yields the largest space. So in the right circumstances eden will be used and more than one pass required.
The bug was that when multiple passes are used the compactor forgot to unmark the corpse left behind when the object was moved. Instead of the corpse being changed into free space it was retained, but its first field would be that of the forwarding pointer to its new location, not the actual first field. So on 32-bits a ByteArray that should have been collected would have its first 4 bytes appear to be invalid, and on 64-bits its first 8 bytes. Because the heap on 64-bits can grow larger it could be that the bug shows itself much less frequently than on 32-bits. When compaction can be completed in a single pass all corpses are correctly collected, so most of the time the bug is hidden.
This is the commit: commit 0fe1e1ea108e53501a0e728736048062c83a66ce Author: Eliot Miranda eliot.miranda@gmail.com Date: Fri Jan 19 13:17:57 2018 -0800
CogVM source as per VMMaker.oscog-eem.2320 Spur: Fix a bad bug in SpurPlnningCompactor.unmarkObjectsFromFirstFreeObject, used when the compactor requires more than one pass due to insufficient savedFirstFieldsSpace, expects the corpse of a moved object to be unmarked, but copyAndUnmarkObject:to:bytes:firstField: only unmarked the target. Unmarking the corpse before the copy unmarks both. This fixes a crash with ReleaseBuilder class>>saveAsNewRelease when non-use of cacheDuring: creates lots of files, enough to push the system into the multi-pass regime.
Hi Alistair,
On Mon, Jan 22, 2018 at 1:42 AM, Alistair Grant akgrant0710@gmail.com wrote:
Hi Eliot,
On Sat, Jan 20, 2018 at 09:19:04AM +0100, Alistair Grant wrote:
Hi Eliot,
On 19 January 2018 at 23:04, Eliot Miranda eliot.miranda@gmail.com
wrote:
Hi Alistair, Hi Cl??ment,
On Fri, Jan 19, 2018 at 12:53 PM, Alistair Grant <
akgrant0710@gmail.com>
wrote:
Hi Cl??ment,
On 19 January 2018 at 17:21, Alistair Grant akgrant0710@gmail.com
wrote:
Hi Cl??ment,
On 19 January 2018 at 17:04, Cl??ment Bera bera.clement@gmail.com wrote:
Does not seem to be related to prim 105.
I suspect that the problem is the same compactor bug I've been trying
to
reproduce all week, and have just fixed. Could you try and reproduce
with a
VM built from the latest commit?
Happy to, but I'm out all day today, so it will be tomorrow or Monday.
Cheers, Alistair (on the run...)
I've tested this with 2 images and 3 VMs in all 6 combinations:
- "Old VM": commit date: Wed Jan 10 23:39:30 2018 -0800, gcc 4.8.5
- "New VM": commit date: Sat Jan 20 13:52:26 2018 +0100, gcc 4.8.5
- "GCC 5 VM": commit date: Sat Jan 20 13:52:26 2018 +0100, gcc 5.4.0
- Clean image: commit id: b28d466f
- Work image: commit id: eb0a6fb1
The gcc 5 is only there because I was playing with it. The results may be useful, or completely misleading. :-)
Each time I ran "5 timesRepeat: [ self test4 ]" with the halts replaced with a count increment. test4 is the method provided in Cyrille's original message.
Result summary:
- Old VM + Work image: 5, 5, 5, 0, 0
- Old VM + Clean image: 5, 5, 0, 0, 0
- New VM + Work image: 5, 0, 5, 5, 5
- New VM + Clean image: 0, 0, 1, 5, 5
- GCC 5 + Work image: 0, 0, 0, 0, 0
- GCC 5 + Clean image: 0, 0, 0, 0, 0
This is strong evidence for the issue being a compiler bug with 4.8.x If exactly the same input source for the Vm wrks with gcc 5 but not with 4.8.x then there is a small chance it is due to the Vm relying on undefined behavior, but I doubt it. Assuming it is a gcc bug then - it should be documented in the HowToBuild files for the relevant platforms - Ci builds should start using gcc 5 and dispense with gcc 4.8.x - since the problem is fixed with gcc 5 there seems little point trying to identify which version of gcc introduces the problem and communicating the problem to the gcc maintainers
What's the status of the bug on Windows and Mac OS X?
Old VM:
5.0-201801110739 Thursday 11 January 09:30:12 CET 2018 gcc 4.8.5 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2302 uuid: 55ec8f63-cdbe-4e79-8f22-48fdea585b88 Jan 11 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2302 uuid: 55ec8f63-cdbe-4e79-8f22-48fdea585b88 Jan 11 2018 VM: 201801110739 alistair@alistair-xps13:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Date: Wed Jan 10 23:39:30 2018 -0800 $ Plugins: 201801110739 alistair@alistair-xps13:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Linux b07d7880072c 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 22:00:44 UTC 2018 i686 i686 i686 GNU/Linux plugin path: /snap/pharo7/x1/usr/bin/pharo-vm32/ [default: /snap/pharo7/x1/usr/bin/pharo-vm32/]
New VM: 5.0-201801201252 Saturday 20 January 21:24:16 CET 2018 gcc 4.8.5 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2320 uuid: e2692e35-5fc8-4623-95d0-b445b3329f75 Jan 20 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2320 uuid: e2692e35-5fc8-4623-95d0-b445b3329f75 Jan 20 2018 VM: 201801201252 alistair@d62ce50f4930:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Date: Sat Jan 20 13:52:26 2018 +0100 $ Plugins: 201801201252 alistair@d62ce50f4930:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Linux 73cbbaa49451 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 22:00:44 UTC 2018 i686 i686 i686 GNU/Linux plugin path: /snap/pharo7/x1/usr/bin/pharo-vm32/ [default: /snap/pharo7/x1/usr/bin/pharo-vm32/]
GCC 5 VM: 5.0-201801201252 Sun Jan 21 14:41:41 UTC 2018 gcc 5.4.0 [Production Spur VM] CoInterpreter VMMaker.oscog-eem.2320 uuid: e2692e35-5fc8-4623-95d0-b445b3329f75 Jan 21 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2320 uuid: e2692e35-5fc8-4623-95d0-b445b3329f75 Jan 21 2018 VM: 201801201252 alistair@alistair-xps13:squeak/opensmalltalk-vm $ Date: Sat Jan 20 13:52:26 2018 +0100 $ Plugins: 201801201252 alistair@alistair-xps13:squeak/opensmalltalk-vm $ Linux ec9d95d2105a 4.13.0-26-generic #29~16.04.2-Ubuntu SMP Tue Jan 9 22:00:44 UTC 2018 i686 i686 i686 GNU/Linux plugin path: /home/alistair/squeak/opensmalltalk-vm/products/ phcogspurlinuxht/lib/pharo/5.0-201801201252 [default: /home/alistair/squeak/opensmalltalk-vm/products/ phcogspurlinuxht/lib/pharo/5.0-201801201252/]
HTH, Alistair
Some details: The SpurPlanningCompactor works by using the fact that all Spur
objects have
room for a forwarding pointer. The compactor make three passes:
- the first pass through memory works out where objects will go,
replacig
their first fields with where they will go, and saving their first
fields in
a buffer (savedFirstFieldsSpace).
- the second pass scans all pointer objects, replacing their fields
with
where the objects referenced will go (following the forwarding
pointers),
and also relocates any pointer fields in savedFirstFieldsSpace
- the final pass slides objects down, restoring their relocated first
fields
The buffer used for savedFirstFieldsSpace determines how many passes
are
used. The system will either use eden (which is empty when compaction occurs) or a large free chunk or allocate a new segment, depending on whatever yields the largest space. So in the right circumstances eden
will
be used and more than one pass required.
The bug was that when multiple passes are used the compactor forgot to unmark the corpse left behind when the object was moved. Instead of
the
corpse being changed into free space it was retained, but its first
field
would be that of the forwarding pointer to its new location, not the
actual
first field. So on 32-bits a ByteArray that should have been collected would have its first 4 bytes appear to be invalid, and on 64-bits its
first
8 bytes. Because the heap on 64-bits can grow larger it could be that
the
bug shows itself much less frequently than on 32-bits. When compaction
can
be completed in a single pass all corpses are correctly collected, so
most
of the time the bug is hidden.
This is the commit: commit 0fe1e1ea108e53501a0e728736048062c83a66ce Author: Eliot Miranda eliot.miranda@gmail.com Date: Fri Jan 19 13:17:57 2018 -0800
CogVM source as per VMMaker.oscog-eem.2320 Spur: Fix a bad bug in SpurPlnningCompactor.unmarkObjectsFromFirstFreeObject, used when the compactor requires more than one pass due to
insufficient
savedFirstFieldsSpace, expects the corpse of a moved object to beunmarked, but copyAndUnmarkObject:to:bytes:firstField: only unmarked the
target.
Unmarking the corpse before the copy unmarks both. This fixes acrash
with ReleaseBuilder class>>saveAsNewRelease when non-use of cacheDuring: creates lots of files, enough to push the system into the multi-pass
regime.
Hi Eliot,
On 23 January 2018 at 01:47, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Alistair,
On Mon, Jan 22, 2018 at 1:42 AM, Alistair Grant akgrant0710@gmail.com wrote:
Hi Eliot,
On Sat, Jan 20, 2018 at 09:19:04AM +0100, Alistair Grant wrote:
Hi Eliot,
On 19 January 2018 at 23:04, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Alistair, Hi Cl??ment,
On Fri, Jan 19, 2018 at 12:53 PM, Alistair Grant akgrant0710@gmail.com wrote:
Hi Cl??ment,
On 19 January 2018 at 17:21, Alistair Grant akgrant0710@gmail.com wrote:
Hi Cl??ment,
On 19 January 2018 at 17:04, Cl??ment Bera bera.clement@gmail.com wrote: > Does not seem to be related to prim 105. >
I suspect that the problem is the same compactor bug I've been trying to reproduce all week, and have just fixed. Could you try and reproduce with a VM built from the latest commit?
Happy to, but I'm out all day today, so it will be tomorrow or Monday.
Cheers, Alistair (on the run...)
I've tested this with 2 images and 3 VMs in all 6 combinations:
- "Old VM": commit date: Wed Jan 10 23:39:30 2018 -0800, gcc 4.8.5
- "New VM": commit date: Sat Jan 20 13:52:26 2018 +0100, gcc 4.8.5
- "GCC 5 VM": commit date: Sat Jan 20 13:52:26 2018 +0100, gcc 5.4.0
- Clean image: commit id: b28d466f
- Work image: commit id: eb0a6fb1
The gcc 5 is only there because I was playing with it. The results may be useful, or completely misleading. :-)
Each time I ran "5 timesRepeat: [ self test4 ]" with the halts replaced with a count increment. test4 is the method provided in Cyrille's original message.
Result summary:
- Old VM + Work image: 5, 5, 5, 0, 0
- Old VM + Clean image: 5, 5, 0, 0, 0
- New VM + Work image: 5, 0, 5, 5, 5
- New VM + Clean image: 0, 0, 1, 5, 5
- GCC 5 + Work image: 0, 0, 0, 0, 0
- GCC 5 + Clean image: 0, 0, 0, 0, 0
This is strong evidence for the issue being a compiler bug with 4.8.x If exactly the same input source for the Vm wrks with gcc 5 but not with 4.8.x then there is a small chance it is due to the Vm relying on undefined behavior, but I doubt it. Assuming it is a gcc bug then
- it should be documented in the HowToBuild files for the relevant platforms
- Ci builds should start using gcc 5 and dispense with gcc 4.8.x
- since the problem is fixed with gcc 5 there seems little point trying to identify which version of gcc introduces the problem and communicating the problem to the gcc maintainers
What's the status of the bug on Windows and Mac OS X?
I can't check MacOS. Clement?
I get the problem on Windows (version info below).
Note that Max Leske and I have been using gcc 4.8 because of a problem with OSProcess and gcc 5 (it possibly doesn't affect me anymore, I'm currently using OSSubprocess). See:
http://lists.squeakfoundation.org/pipermail/vm-dev/2017-May/025216.html
I'll try and confirm correct OSSubprocess operation with gcc 5, but it will take a while, I'm battling too many different problems at the moment:
- TZ and DST handling on Windows - Windows VM suddenly can't find any of its plugins. Is anyone else seeing strange behaviour here with VMs from the last few days? -- It looks like the plugin handling mechanism is completely different on Windows to Unix, so the VM doesn't report where it is looking and doesn't provide the option to specify the directory. Grrrrrgh. - My linux build environment. - real life :-)
Windows version info:
OS: Windows 10 Image: Pharo 7.0 Build information: Pharo-7.0+alpha.build.439.sha.481071068244d0484241924f79ba791f80701316 (32 Bit) VM: Win32 built on Nov 27 2017 00:05:44 GMT Compiler: 6.4.0 [Production Spur VM] CoInterpreter VMMaker.oscog- nice.2281 uuid: 4beeaee7-567e-1a4b-b0fb-bd95ce302516 Nov 27 2017 StackToRegisterMappingCogit VMMaker.oscog-nice.2283 uuid: 2d20324d-a2ab-48d6-b0f6-9fc3d66899da Nov 27 2017 VM: 201711262336 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Mon Nov 27 00:36:29 2017 +0100 $ Plugins: 201711262336 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Cheers, Alistair
I'm curious to test both of these problems on obsd but don't know what to do to make the problem manifest itself, so if anyone could toss me a (preferably non-null) pointer, that'd be great.
Thanks,
Stu
---------- Original Message ---------- From: Alistair Grant akgrant0710@gmail.com Date: January 23, 2018 at 3:24 AM
Hi Eliot,
On 23 January 2018 at 01:47, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Alistair,
On Mon, Jan 22, 2018 at 1:42 AM, Alistair Grant akgrant0710@gmail.com wrote:
Hi Eliot,
On Sat, Jan 20, 2018 at 09:19:04AM +0100, Alistair Grant wrote:
Hi Eliot,
On 19 January 2018 at 23:04, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Alistair, Hi Cl??ment,
On Fri, Jan 19, 2018 at 12:53 PM, Alistair Grant akgrant0710@gmail.com wrote:
Hi Cl??ment,
On 19 January 2018 at 17:21, Alistair Grant akgrant0710@gmail.com wrote: > Hi Cl??ment, > > On 19 January 2018 at 17:04, Cl??ment Bera bera.clement@gmail.com > wrote: >> Does not seem to be related to prim 105. >>
I suspect that the problem is the same compactor bug I've been trying to reproduce all week, and have just fixed. Could you try and reproduce with a VM built from the latest commit?
Happy to, but I'm out all day today, so it will be tomorrow or Monday.
Cheers, Alistair (on the run...)
I've tested this with 2 images and 3 VMs in all 6 combinations:
- "Old VM": commit date: Wed Jan 10 23:39:30 2018 -0800, gcc 4.8.5
- "New VM": commit date: Sat Jan 20 13:52:26 2018 +0100, gcc 4.8.5
- "GCC 5 VM": commit date: Sat Jan 20 13:52:26 2018 +0100, gcc 5.4.0
- Clean image: commit id: b28d466f
- Work image: commit id: eb0a6fb1
The gcc 5 is only there because I was playing with it. The results may be useful, or completely misleading. :-)
Each time I ran "5 timesRepeat: [ self test4 ]" with the halts replaced with a count increment. test4 is the method provided in Cyrille's original message.
Result summary:
- Old VM + Work image: 5, 5, 5, 0, 0
- Old VM + Clean image: 5, 5, 0, 0, 0
- New VM + Work image: 5, 0, 5, 5, 5
- New VM + Clean image: 0, 0, 1, 5, 5
- GCC 5 + Work image: 0, 0, 0, 0, 0
- GCC 5 + Clean image: 0, 0, 0, 0, 0
This is strong evidence for the issue being a compiler bug with 4.8.x If exactly the same input source for the Vm wrks with gcc 5 but not with 4.8.x then there is a small chance it is due to the Vm relying on undefined behavior, but I doubt it. Assuming it is a gcc bug then
- it should be documented in the HowToBuild files for the relevant platforms
- Ci builds should start using gcc 5 and dispense with gcc 4.8.x
- since the problem is fixed with gcc 5 there seems little point trying to identify which version of gcc introduces the problem and communicating the problem to the gcc maintainers
What's the status of the bug on Windows and Mac OS X?
I can't check MacOS. Clement?
I get the problem on Windows (version info below).
Note that Max Leske and I have been using gcc 4.8 because of a problem with OSProcess and gcc 5 (it possibly doesn't affect me anymore, I'm currently using OSSubprocess). See:
http://lists.squeakfoundation.org/pipermail/vm-dev/2017-May/025216.html
I'll try and confirm correct OSSubprocess operation with gcc 5, but it will take a while, I'm battling too many different problems at the moment:
- TZ and DST handling on Windows
- Windows VM suddenly can't find any of its plugins. Is anyone else
seeing strange behaviour here with VMs from the last few days? -- It looks like the plugin handling mechanism is completely different on Windows to Unix, so the VM doesn't report where it is looking and doesn't provide the option to specify the directory. Grrrrrgh.
- My linux build environment.
- real life :-)
Windows version info:
OS: Windows 10 Image: Pharo 7.0 Build information: Pharo-7.0+alpha.build.439.sha.481071068244d0484241924f79ba791f80701316 (32 Bit) VM: Win32 built on Nov 27 2017 00:05:44 GMT Compiler: 6.4.0 [Production Spur VM] CoInterpreter VMMaker.oscog- nice.2281 uuid: 4beeaee7-567e-1a4b-b0fb-bd95ce302516 Nov 27 2017 StackToRegisterMappingCogit VMMaker.oscog-nice.2283 uuid: 2d20324d-a2ab-48d6-b0f6-9fc3d66899da Nov 27 2017 VM: 201711262336 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $ Date: Mon Nov 27 00:36:29 2017 +0100 $ Plugins: 201711262336 https://github.com/OpenSmalltalk/opensmalltalk-vm.git $
Cheers, Alistair
Hi Stu,
On 23 January 2018 at 16:15, Stuart Cassoff aa72@bell.net wrote:
I'm curious to test both of these problems on obsd but don't know what to do to make the problem manifest itself, so if anyone could toss me a (preferably non-null) pointer, that'd be great.
Thanks,
Stu
Just run #test4 (several times :-)) as defined in the original post.
Cheers, Alistair --
test4 "self test4" | species bufferSize buffer totalRead outputStream answer inputStream ba byte1 | ba := ByteArray new: 18202085. ba atAllPut: 99. 1 to: 20 do: [ :i | ba at: i put: (#[80 75 3 4 10 7 7 7 7 7 125 83 67 73 7 7 7 7 7 7] at: i) ]. inputStream := ba readStream. bufferSize := 16384. species := ByteArray. buffer := species new: bufferSize. totalRead := 0. outputStream := nil. [ inputStream atEnd ] whileFalse: [ | readCount | readCount := inputStream readInto: buffer startingAt: 1 count: bufferSize. totalRead = 0 ifTrue: [ byte1 := buffer first. ]. totalRead := totalRead + readCount.
outputStream ifNil: [ inputStream atEnd ifTrue: [ ^ buffer copyFrom: 1 to: readCount ] ifFalse: [ outputStream := (species new: bufferSize) writeStream ] ]. outputStream next: readCount putAll: buffer startingAt: 1. byte1 = outputStream contents first ifFalse: [ self halt ]. ]. answer := outputStream ifNil: [ species new ] ifNotNil: [ outputStream contents ]. byte1 = answer first ifFalse: [ self halt ]. ^answer --
Thanks! Yeah, sorry, I couldn't find the original thread. Anyway I don't really know what to do with this so I pasted into a workspace and hit alt-p. After a while I get a debug popup telling me about something not understanding 'halt'. fyi I've not yet written a line of Smalltalk code in my life so maybe I'm biting off more than I can chew. I get the impression I should make a method 'test4' in some number class. *shrug* Anyway, here's part of the SqueakDebug.log that may be useful.
Stu
UndefinedObject>>DoIt Receiver: nil Arguments and temporary variables: species: ByteArray bufferSize: 16384 buffer: #[99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 ...etc... totalRead: 18202085 outputStream: a WriteStream answer: #[99 99 99 99 10 7 7 7 7 7 125 83 67 73 7 7 7 7 7 7 99 99 99 99 99 99 9...etc... inputStream: a ReadStream ba: #[80 75 3 4 10 7 7 7 7 7 125 83 67 73 7 7 7 7 7 7 99 99 99 99 99 99 99 99 9...etc... byte1: 80 i: 21 readCount: 15845 Receiver's instance variables: nil
---------- Original Message ---------- From: Alistair Grant akgrant0710@gmail.com Date: January 23, 2018 at 10:40 AM
Hi Stu,
On 23 January 2018 at 16:15, Stuart Cassoff aa72@bell.net wrote:
I'm curious to test both of these problems on obsd but don't know what to do to make the problem manifest itself, so if anyone could toss me a (preferably non-null) pointer, that'd be great.
Thanks,
Stu
Just run #test4 (several times :-)) as defined in the original post.
Cheers, Alistair --
test4 "self test4" | species bufferSize buffer totalRead outputStream answer inputStream ba byte1 | ba := ByteArray new: 18202085. ba atAllPut: 99. 1 to: 20 do: [ :i | ba at: i put: (#[80 75 3 4 10 7 7 7 7 7 125 83 67 73 7 7 7 7 7 7] at: i) ]. inputStream := ba readStream. bufferSize := 16384. species := ByteArray. buffer := species new: bufferSize. totalRead := 0. outputStream := nil. [ inputStream atEnd ] whileFalse: [ | readCount | readCount := inputStream readInto: buffer startingAt: 1 count: bufferSize. totalRead = 0 ifTrue: [ byte1 := buffer first. ]. totalRead := totalRead + readCount.
outputStream ifNil: [ inputStream atEnd ifTrue: [ ^ buffer copyFrom: 1 to: readCount ] ifFalse: [ outputStream := (species new: bufferSize)writeStream ] ]. outputStream next: readCount putAll: buffer startingAt: 1. byte1 = outputStream contents first ifFalse: [ self halt ]. ]. answer := outputStream ifNil: [ species new ] ifNotNil: [ outputStream contents ]. byte1 = answer first ifFalse: [ self halt ]. ^answer --
Hi Stu,
On 23 January 2018 at 21:33, Stuart Cassoff aa72@bell.net wrote:
Thanks! Yeah, sorry, I couldn't find the original thread. Anyway I don't really know what to do with this so I pasted into a workspace and hit alt-p. After a while I get a debug popup telling me about something not understanding 'halt'. fyi I've not yet written a line of Smalltalk code in my life so maybe I'm biting off more than I can chew. I get the impression I should make a method 'test4' in some number class. *shrug* Anyway, here's part of the SqueakDebug.log that may be useful.
Jumping in the deep end! :-)
I assumed that you're familiar with Smalltalk.
What was originally supplied was the source for a method, but no class definition.
I threw together a class which runs the method five times and shows the results.
You should be able to:
1. file in the attached source. You can open a File List (Tools -> File List), select the file and right click "install into new change set". 2. Find AKGRandomCorruption in the System Browser to check that it loaded OK. 3. Open a workspace and DoIt "AKGRandomCorruption backgroundRun".
If you want to check that the process is really running, open a process browser and look for "Corruption attempt" at priority 20.
That will open an inspector, and the whole system will slow down. It runs the test in a separate smalltalk process at low priority. Eventually a "Halt" window will pop up, which you can Abandon.
Then look at "count" and "corruptions" in the inspector. Anything greater than 0 is bad. :-)
When you report back, please let us know:
1. Your operating system 2. Squeak version - open "About Squeak..." and copy all the text from the Image and Virtual Machine sections.
Thanks for your offer to help! Alistair
Stu
UndefinedObject>>DoIt Receiver: nil Arguments and temporary variables: species: ByteArray bufferSize: 16384 buffer: #[99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 ...etc... totalRead: 18202085 outputStream: a WriteStream answer: #[99 99 99 99 10 7 7 7 7 7 125 83 67 73 7 7 7 7 7 7 99 99 99 99 99 99 9...etc... inputStream: a ReadStream ba: #[80 75 3 4 10 7 7 7 7 7 125 83 67 73 7 7 7 7 7 7 99 99 99 99 99 99 99 99 9...etc... byte1: 80 i: 21 readCount: 15845 Receiver's instance variables: nil
---------- Original Message ---------- From: Alistair Grant akgrant0710@gmail.com Date: January 23, 2018 at 10:40 AM
Hi Stu,
On 23 January 2018 at 16:15, Stuart Cassoff aa72@bell.net wrote:
I'm curious to test both of these problems on obsd but don't know what to do to make the problem manifest itself, so if anyone could toss me a (preferably non-null) pointer, that'd be great.
Thanks,
Stu
Just run #test4 (several times :-)) as defined in the original post.
Cheers, Alistair --
test4 "self test4" | species bufferSize buffer totalRead outputStream answer inputStream ba byte1 | ba := ByteArray new: 18202085. ba atAllPut: 99. 1 to: 20 do: [ :i | ba at: i put: (#[80 75 3 4 10 7 7 7 7 7 125 83 67 73 7 7 7 7 7 7] at: i) ]. inputStream := ba readStream. bufferSize := 16384. species := ByteArray. buffer := species new: bufferSize. totalRead := 0. outputStream := nil. [ inputStream atEnd ] whileFalse: [ | readCount | readCount := inputStream readInto: buffer startingAt: 1 count: bufferSize. totalRead = 0 ifTrue: [ byte1 := buffer first. ]. totalRead := totalRead + readCount.
outputStream ifNil: [ inputStream atEnd ifTrue: [ ^ buffer copyFrom: 1 to: readCount ] ifFalse: [ outputStream := (species new: bufferSize)writeStream ] ]. outputStream next: readCount putAll: buffer startingAt: 1. byte1 = outputStream contents first ifFalse: [ self halt ]. ]. answer := outputStream ifNil: [ species new ] ifNotNil: [ outputStream contents ]. byte1 = answer first ifFalse: [ self halt ]. ^answer --
On 23 January 2018 at 21:33, Stuart Cassoff aa72@bell.net wrote:
Thanks! Yeah, sorry, I couldn't find the original thread. Anyway I don't really know what to do with this so I pasted into a workspace and hit alt-p. After a while I get a debug popup telling me about something not understanding 'halt'. fyi I've not yet written a line of Smalltalk code in my life so maybe I'm biting off more than I can chew.
OK Stuart, pop over to https://www.youtube.com/watch?v=Es7RyllOS-M&list=PL6601A198DF14788D and watch your way through Lawson’s nice playlist of introduction to smalltalk videos. They’re a little out of date in some UI details (being based on the 4.x era of Squeak) but I don’t think anything has changed that would cause serious mental distress.
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- All foam, no beer.
Thanks! I've watched all those, plus all 140 of these https://www.youtube.com/user/gandysmedicineshow plus all of these (which are way better Lawson's) https://www.youtube.com/playlist?list=PL9fxnlyTJbh-li3QlVytbvGXHOw1SaXv3 plus another handful of Alan Kay and Dan Ingalls vids, plus talks on a range of Smalltalk topics, plus... Many I've watched more than once, even. I've also read articles, blogs, papers, etc. I've got a pretty good grasp of the language and basic tools usage. I'm now moving from the theory to the practice phase. I've still got to figure out a few more things but now that's mostly Monticello-ish-y stuff.
fyi, I program mainly in C and Tcl, and I do some porting so I'm somewhat handy with autoconf et al.
Right now Pharo sez my vm is too old but it turns out that's because I'm getting a 'subscript out of bounds' when I do a 'Smalltalk vm interpreterSourceDate'. *shrug*
I'll have some test results shortly.
Stu
---------- Original Message ---------- From: tim Rowledge tim@rowledge.org Date: January 24, 2018 at 1:37 PM
On 23 January 2018 at 21:33, Stuart Cassoff aa72@bell.net wrote:
Thanks! Yeah, sorry, I couldn't find the original thread. Anyway I don't really know what to do with this so I pasted into a workspace and hit alt-p. After a while I get a debug popup telling me about something not understanding 'halt'. fyi I've not yet written a line of Smalltalk code in my life so maybe I'm biting off more than I can chew.
OK Stuart, pop over to https://www.youtube.com/watch?v=Es7RyllOS-M&list=PL6601A198DF14788D and watch your way through Lawson’s nice playlist of introduction to smalltalk videos. They’re a little out of date in some UI details (being based on the 4.x era of Squeak) but I don’t think anything has changed that would cause serious mental distress.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- All foam, no beer.
"...cause serious mental distress." He speaks so slowly and futzes around so much that I want to self-harm, but otherwise good. :)
Forgot to mention that I really really like Smalltalk. It's mind-blowingly amazing and learning it has made a big difference in my programming life and has even influenced a bit how I program in other languages.
Stu
---------- Original Message ---------- From: Stuart Cassoff aa72@bell.net Date: January 24, 2018 at 3:58 PM
Thanks! I've watched all those, plus all 140 of these https://www.youtube.com/user/gandysmedicineshow plus all of these (which are way better Lawson's) https://www.youtube.com/playlist?list=PL9fxnlyTJbh-li3QlVytbvGXHOw1SaXv3 plus another handful of Alan Kay and Dan Ingalls vids, plus talks on a range of Smalltalk topics, plus... Many I've watched more than once, even. I've also read articles, blogs, papers, etc. I've got a pretty good grasp of the language and basic tools usage. I'm now moving from the theory to the practice phase. I've still got to figure out a few more things but now that's mostly Monticello-ish-y stuff.
fyi, I program mainly in C and Tcl, and I do some porting so I'm somewhat handy with autoconf et al.
Right now Pharo sez my vm is too old but it turns out that's because I'm getting a 'subscript out of bounds' when I do a 'Smalltalk vm interpreterSourceDate'. *shrug*
I'll have some test results shortly.
Stu
---------- Original Message ---------- From: tim Rowledge tim@rowledge.org Date: January 24, 2018 at 1:37 PM
On 23 January 2018 at 21:33, Stuart Cassoff aa72@bell.net wrote:
Thanks! Yeah, sorry, I couldn't find the original thread. Anyway I don't really know what to do with this so I pasted into a workspace and hit alt-p. After a while I get a debug popup telling me about something not understanding 'halt'. fyi I've not yet written a line of Smalltalk code in my life so maybe I'm biting off more than I can chew.
OK Stuart, pop over to https://www.youtube.com/watch?v=Es7RyllOS-M&list=PL6601A198DF14788D and watch your way through Lawson’s nice playlist of introduction to smalltalk videos. They’re a little out of date in some UI details (being based on the 4.x era of Squeak) but I don’t think anything has changed that would cause serious mental distress.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- All foam, no beer.
On 25 January 2018 at 05:04, Stuart Cassoff aa72@bell.net wrote:
"...cause serious mental distress." He speaks so slowly and futzes around so much that I want to self-harm, but otherwise good. :)
Forgot to mention that I really really like Smalltalk. It's mind-blowingly amazing
great to hear you're having fun.
and learning it has made a big difference in my programming life and has even influenced a bit how I program in other languages.
If you haven't already, get hold of a Mentoring Course on Smalltalk. It provides a good perspective on how to approach things differently in Smalltalk than other languages. http://www.lulu.com/au/en/shop/andres-valloud/a-mentoring-course-on-smalltal...
cheers -ben
Stu
---------- Original Message ---------- From: Stuart Cassoff aa72@bell.net Date: January 24, 2018 at 3:58 PM
Thanks! I've watched all those, plus all 140 of these https://www.youtube.com/user/gandysmedicineshow plus all of these (which are way better Lawson's) https://www.youtube.com/playlist?list=PL9fxnlyTJbh-li3QlVytbvGXHOw1SaXv3 plus another handful of Alan Kay and Dan Ingalls vids, plus talks on a range of Smalltalk topics, plus... Many I've watched more than once, even. I've also read articles, blogs, papers, etc. I've got a pretty good grasp of the language and basic tools usage. I'm now moving from the theory to the practice phase. I've still got to figure out a few more things but now that's mostly Monticello-ish-y stuff.
fyi, I program mainly in C and Tcl, and I do some porting so I'm somewhat handy with autoconf et al.
Right now Pharo sez my vm is too old but it turns out that's because I'm getting a 'subscript out of bounds' when I do a 'Smalltalk vm interpreterSourceDate'. *shrug*
I'll have some test results shortly.
Stu
---------- Original Message ---------- From: tim Rowledge tim@rowledge.org Date: January 24, 2018 at 1:37 PM
On 23 January 2018 at 21:33, Stuart Cassoff aa72@bell.net wrote:
Thanks! Yeah, sorry, I couldn't find the original thread. Anyway I don't really know what to do with this so I pasted into a workspace and hit alt-p. After a while I get a debug popup telling me about something not understanding 'halt'. fyi I've not yet written a line of Smalltalk code in my life so maybe I'm biting off more than I can chew.
OK Stuart, pop over to https://www.youtube.com/watch?v=Es7RyllOS-M&list=PL6601A198DF14788D and watch your way through Lawson’s nice playlist of introduction to smalltalk videos. They’re a little out of date in some UI details (being based on the 4.x era of Squeak) but I don’t think anything has changed that would cause serious mental distress.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- All foam, no beer.
Thanks!
---------- Original Message ---------- From: Ben Coman btc@openinworld.com Date: January 24, 2018 at 4:55 PM
On 25 January 2018 at 05:04, Stuart Cassoff aa72@bell.net wrote:
"...cause serious mental distress." He speaks so slowly and futzes around so much that I want to self-harm, but otherwise good. :)
Forgot to mention that I really really like Smalltalk. It's mind-blowingly amazing
great to hear you're having fun.
and learning it has made a big difference in my programming life and has even influenced a bit how I program in other languages.
If you haven't already, get hold of a Mentoring Course on Smalltalk. It provides a good perspective on how to approach things differently in Smalltalk than other languages. http://www.lulu.com/au/en/shop/andres-valloud/a-mentoring-course-on-smalltal...
cheers -ben
Stu
---------- Original Message ---------- From: Stuart Cassoff aa72@bell.net Date: January 24, 2018 at 3:58 PM
Thanks! I've watched all those, plus all 140 of these https://www.youtube.com/user/gandysmedicineshow plus all of these (which are way better Lawson's) https://www.youtube.com/playlist?list=PL9fxnlyTJbh-li3QlVytbvGXHOw1SaXv3 plus another handful of Alan Kay and Dan Ingalls vids, plus talks on a range of Smalltalk topics, plus... Many I've watched more than once, even. I've also read articles, blogs, papers, etc. I've got a pretty good grasp of the language and basic tools usage. I'm now moving from the theory to the practice phase. I've still got to figure out a few more things but now that's mostly Monticello-ish-y stuff.
fyi, I program mainly in C and Tcl, and I do some porting so I'm somewhat handy with autoconf et al.
Right now Pharo sez my vm is too old but it turns out that's because I'm getting a 'subscript out of bounds' when I do a 'Smalltalk vm interpreterSourceDate'. *shrug*
I'll have some test results shortly.
Stu
---------- Original Message ---------- From: tim Rowledge tim@rowledge.org Date: January 24, 2018 at 1:37 PM
On 23 January 2018 at 21:33, Stuart Cassoff aa72@bell.net wrote:
Thanks! Yeah, sorry, I couldn't find the original thread. Anyway I don't really know what to do with this so I pasted into a workspace and hit alt-p. After a while I get a debug popup telling me about something not understanding 'halt'. fyi I've not yet written a line of Smalltalk code in my life so maybe I'm biting off more than I can chew.
OK Stuart, pop over to https://www.youtube.com/watch?v=Es7RyllOS-M&list=PL6601A198DF14788D and watch your way through Lawson’s nice playlist of introduction to smalltalk videos. They’re a little out of date in some UI details (being based on the 4.x era of Squeak) but I don’t think anything has changed that would cause serious mental distress.
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- All foam, no beer.
On 24 January 2018 at 21:58, Stuart Cassoff aa72@bell.net wrote:
Right now Pharo sez my vm is too old but it turns out that's because I'm getting a 'subscript out of bounds' when I do a 'Smalltalk vm interpreterSourceDate'. *shrug*
Is this a vm you compiled yourself?
If so, you need to run scripts/updateSCCSVersions before compiling.
Cheers, Alistair
Yes, all my VMs are built as OpenBSD ports. Thanks for the tip on updateSCCSVersions - I suspect I'll get nicer version strings now. :) That's great though, now that I understand. The tip-off was from Pharo. What do you want me to test on? With your instructions I'm now running the test in Squeak-5.1 but I have 6.0alpha, and Pharo 5,6 and 7.
Stu
---------- Original Message ---------- From: Alistair Grant akgrant0710@gmail.com Date: January 24, 2018 at 4:04 PM
On 24 January 2018 at 21:58, Stuart Cassoff aa72@bell.net wrote:
Right now Pharo sez my vm is too old but it turns out that's because I'm getting a 'subscript out of bounds' when I do a 'Smalltalk vm interpreterSourceDate'. *shrug*
Is this a vm you compiled yourself?
If so, you need to run scripts/updateSCCSVersions before compiling.
Cheers, Alistair
Hi Stu,
On 24 January 2018 at 22:24, Stuart Cassoff aa72@bell.net wrote:
Yes, all my VMs are built as OpenBSD ports. Thanks for the tip on updateSCCSVersions - I suspect I'll get nicer version strings now. :) That's great though, now that I understand. The tip-off was from Pharo. What do you want me to test on? With your instructions I'm now running the test in Squeak-5.1 but I have 6.0alpha, and Pharo 5,6 and 7.
I assume you're compiling with gcc. It would be great if you could try to reproduce the problem with gcc 4.8.x and >= 5.4.x.
The other important attributes:
- 32 bit VM - VM from commit >= Fri Jan 19 13:17:57 2018 -0800
Other than that, whether you use Squeak or Pharo is up to you.
I've found the problem tends to appear more often if the test is run immediately after starting Squeak / Pharo.
Thanks! Alistair
Stu
---------- Original Message ---------- From: Alistair Grant akgrant0710@gmail.com Date: January 24, 2018 at 4:04 PM
On 24 January 2018 at 21:58, Stuart Cassoff aa72@bell.net wrote:
Right now Pharo sez my vm is too old but it turns out that's because I'm getting a 'subscript out of bounds' when I do a 'Smalltalk vm interpreterSourceDate'. *shrug*
Is this a vm you compiled yourself?
If so, you need to run scripts/updateSCCSVersions before compiling.
Cheers, Alistair
Aw, yeah! I could see that stuff was for filling-in but I'd forgotten about it, and so I found your little smudge hidden away which gave me the skinny on the deal and now I've got it setup in the port. Very pleased. Is there anything else like this that needs to be done when building?
Here's another result. I still get a count of 30 but tried it in a different interp.
Thanks!
Stu
Image ----- /tmp/p/Squeak5.1-16551-32bit.image Squeak5.1 latest update: #16551 Current Change Set: Unnamed1 Image format 6521 (32 bit)
Virtual Machine --------------- /usr/ports/pobj/ostV_squeak_sista_spur-5.1/build-i386/squeak Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2320] Unix built on Jan 25 2018 00:24:25 Compiler: 4.2.1 Compatible OpenBSD Clang 5.0.1 (tags/RELEASE_501/final) platform sources revision VM: 201801241742 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Wed Jan 24 18:42:19 2018 +0100 Plugins: 201801241742 https://github.com/OpenSmalltalk/opensmalltalk-vm.git CoInterpreter VMMaker.oscog-eem.2320 uuid: e2692e35-5fc8-4623-95d0-b445b3329f75 Jan 25 2018 SistaCogit VMMaker.oscog-eem.2324 uuid: 904abc56-e5a8-467e-a337-880211e33805 Jan 25 2018
---------- Original Message ---------- From: Alistair Grant akgrant0710@gmail.com Date: January 24, 2018 at 4:04 PM
On 24 January 2018 at 21:58, Stuart Cassoff aa72@bell.net wrote:
Right now Pharo sez my vm is too old but it turns out that's because I'm getting a 'subscript out of bounds' when I do a 'Smalltalk vm interpreterSourceDate'. *shrug*
Is this a vm you compiled yourself?
If so, you need to run scripts/updateSCCSVersions before compiling.
Cheers, Alistair
Silly me, I really should read the docs that come with. :/
---------- Original Message ---------- From: Stuart Cassoff aa72@bell.net Date: January 25, 2018 at 9:15 AM
Aw, yeah! I could see that stuff was for filling-in but I'd forgotten about it, and so I found your little smudge hidden away which gave me the skinny on the deal and now I've got it setup in the port. Very pleased. Is there anything else like this that needs to be done when building?
Here's another result. I still get a count of 30 but tried it in a different interp.
Thanks!
Stu
Image
/tmp/p/Squeak5.1-16551-32bit.image Squeak5.1 latest update: #16551 Current Change Set: Unnamed1 Image format 6521 (32 bit)
Virtual Machine
/usr/ports/pobj/ostV_squeak_sista_spur-5.1/build-i386/squeak Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2320] Unix built on Jan 25 2018 00:24:25 Compiler: 4.2.1 Compatible OpenBSD Clang 5.0.1 (tags/RELEASE_501/final) platform sources revision VM: 201801241742 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Wed Jan 24 18:42:19 2018 +0100 Plugins: 201801241742 https://github.com/OpenSmalltalk/opensmalltalk-vm.git CoInterpreter VMMaker.oscog-eem.2320 uuid: e2692e35-5fc8-4623-95d0-b445b3329f75 Jan 25 2018 SistaCogit VMMaker.oscog-eem.2324 uuid: 904abc56-e5a8-467e-a337-880211e33805 Jan 25 2018
---------- Original Message ---------- From: Alistair Grant akgrant0710@gmail.com Date: January 24, 2018 at 4:04 PM
On 24 January 2018 at 21:58, Stuart Cassoff aa72@bell.net wrote:
Right now Pharo sez my vm is too old but it turns out that's because I'm getting a 'subscript out of bounds' when I do a 'Smalltalk vm interpreterSourceDate'. *shrug*
Is this a vm you compiled yourself?
If so, you need to run scripts/updateSCCSVersions before compiling.
Cheers, Alistair
Count is 30!
$ uname -mrsv OpenBSD 6.2 GENERIC.MP#382 i386
Image ----- /tmp/p/Squeak5.1-16551-32bit.image Squeak5.1 latest update: #16551 Current Change Set: Unnamed1 Image format 6521 (32 bit)
Virtual Machine --------------- /usr/ports/pobj/ostV_pharo_cog_spur-5.1/build-i386/squeak Croquet Closure Cog[Spur] VM [CoInterpreterPrimitives VMMaker.oscog-eem.2320] Unix built on Jan 24 2018 14:19:31 Compiler: 4.2.1 Compatible OpenBSD Clang 5.0.1 (tags/RELEASE_501/final) platform sources revision VM: $Date$ Date: $Rev$ Plugins: $URL$ $Rev$ CoInterpreter VMMaker.oscog-eem.2320 uuid: e2692e35-5fc8-4623-95d0-b445b3329f75 Jan 24 2018 StackToRegisterMappingCogit VMMaker.oscog-eem.2324 uuid: 904abc56-e5a8-467e-a337-880211e33805 Jan 24 2018
Stu
---------- Original Message ---------- From: Alistair Grant akgrant0710@gmail.com Date: January 24, 2018 at 11:34 AM
Hi Stu,
On 23 January 2018 at 21:33, Stuart Cassoff aa72@bell.net wrote:
Thanks! Yeah, sorry, I couldn't find the original thread. Anyway I don't really know what to do with this so I pasted into a workspace and hit alt-p. After a while I get a debug popup telling me about something not understanding 'halt'. fyi I've not yet written a line of Smalltalk code in my life so maybe I'm biting off more than I can chew. I get the impression I should make a method 'test4' in some number class. *shrug* Anyway, here's part of the SqueakDebug.log that may be useful.
Jumping in the deep end! :-)
I assumed that you're familiar with Smalltalk.
What was originally supplied was the source for a method, but no class definition.
I threw together a class which runs the method five times and shows the results.
You should be able to:
- file in the attached source. You can open a File List (Tools ->
File List), select the file and right click "install into new change set". 2. Find AKGRandomCorruption in the System Browser to check that it loaded OK. 3. Open a workspace and DoIt "AKGRandomCorruption backgroundRun".
If you want to check that the process is really running, open a process browser and look for "Corruption attempt" at priority 20.
That will open an inspector, and the whole system will slow down. It runs the test in a separate smalltalk process at low priority. Eventually a "Halt" window will pop up, which you can Abandon.
Then look at "count" and "corruptions" in the inspector. Anything greater than 0 is bad. :-)
When you report back, please let us know:
- Your operating system
- Squeak version - open "About Squeak..." and copy all the text from
the Image and Virtual Machine sections.
Thanks for your offer to help! Alistair
Stu
UndefinedObject>>DoIt Receiver: nil Arguments and temporary variables: species: ByteArray bufferSize: 16384 buffer: #[99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 99 ...etc... totalRead: 18202085 outputStream: a WriteStream answer: #[99 99 99 99 10 7 7 7 7 7 125 83 67 73 7 7 7 7 7 7 99 99 99 99 99 99 9...etc... inputStream: a ReadStream ba: #[80 75 3 4 10 7 7 7 7 7 125 83 67 73 7 7 7 7 7 7 99 99 99 99 99 99 99 99 9...etc... byte1: 80 i: 21 readCount: 15845 Receiver's instance variables: nil
---------- Original Message ---------- From: Alistair Grant akgrant0710@gmail.com Date: January 23, 2018 at 10:40 AM
Hi Stu,
On 23 January 2018 at 16:15, Stuart Cassoff aa72@bell.net wrote:
I'm curious to test both of these problems on obsd but don't know what to do to make the problem manifest itself, so if anyone could toss me a (preferably non-null) pointer, that'd be great.
Thanks,
Stu
Just run #test4 (several times :-)) as defined in the original post.
Cheers, Alistair --
test4 "self test4" | species bufferSize buffer totalRead outputStream answer inputStream ba byte1 | ba := ByteArray new: 18202085. ba atAllPut: 99. 1 to: 20 do: [ :i | ba at: i put: (#[80 75 3 4 10 7 7 7 7 7 125 83 67 73 7 7 7 7 7 7] at: i) ]. inputStream := ba readStream. bufferSize := 16384. species := ByteArray. buffer := species new: bufferSize. totalRead := 0. outputStream := nil. [ inputStream atEnd ] whileFalse: [ | readCount | readCount := inputStream readInto: buffer startingAt: 1 count: bufferSize. totalRead = 0 ifTrue: [ byte1 := buffer first. ]. totalRead := totalRead + readCount.
outputStream ifNil: [ inputStream atEnd ifTrue: [ ^ buffer copyFrom: 1 to: readCount ] ifFalse: [ outputStream := (species new: bufferSize)writeStream ] ]. outputStream next: readCount putAll: buffer startingAt: 1. byte1 = outputStream contents first ifFalse: [ self halt ]. ]. answer := outputStream ifNil: [ species new ] ifNotNil: [ outputStream contents ]. byte1 = answer first ifFalse: [ self halt ]. ^answer --
vm-dev@lists.squeakfoundation.org
-
Alistair Grant -
Ben Coman -
Eliot Miranda -
Stuart Cassoff -
tim Rowledge