Re: [Pharo-dev] Random corrupted data when copying from very large byte array

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

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

alistairgrant
 
Hi Eliot,

On 19 January 2018 at 23:04, Eliot Miranda <[hidden email]> wrote:

> Hi Alistair, Hi Clément,
>
> On Fri, Jan 19, 2018 at 12:53 PM, Alistair Grant <[hidden email]>
> wrote:
>>
>> Hi Clément,
>>
>> On 19 January 2018 at 17:21, Alistair Grant <[hidden email]> wrote:
>> > Hi Clément,
>> >
>> > On 19 January 2018 at 17:04, Clément Bera <[hidden email]>
>> > 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 <[hidden email]>
> 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 <[hidden email]>
>> >> 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
>> >>> <[hidden email]> 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 <[hidden email]>:
>> >>>>>
>> >>>>> 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-from-very-large-byte-array
>> >>>>>
>> >>>>> 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
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

alistairgrant
 
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 <[hidden email]> wrote:
> > Hi Alistair, Hi Cl??ment,
> >
> > On Fri, Jan 19, 2018 at 12:53 PM, Alistair Grant <[hidden email]>
> > wrote:
> >>
> >> Hi Cl??ment,
> >>
> >> On 19 January 2018 at 17:21, Alistair Grant <[hidden email]> wrote:
> >> > Hi Cl??ment,
> >> >
> >> > On 19 January 2018 at 17:04, Cl??ment Bera <[hidden email]>
> >> > 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 <[hidden email]>
> > 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.
> >
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

Eliot Miranda-2
 
Hi Alistair,

On Mon, Jan 22, 2018 at 1:42 AM, Alistair Grant <[hidden email]> 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 <[hidden email]> wrote:
> > Hi Alistair, Hi Cl??ment,
> >
> > On Fri, Jan 19, 2018 at 12:53 PM, Alistair Grant <[hidden email]>
> > wrote:
> >>
> >> Hi Cl??ment,
> >>
> >> On 19 January 2018 at 17:21, Alistair Grant <[hidden email]> wrote:
> >> > Hi Cl??ment,
> >> >
> >> > On 19 January 2018 at 17:04, Cl??ment Bera <[hidden email]>
> >> > 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 <[hidden email]>
> > 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.
> >



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

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

alistairgrant
 
Hi Eliot,

On 23 January 2018 at 01:47, Eliot Miranda <[hidden email]> wrote:

>
> Hi Alistair,
>
> On Mon, Jan 22, 2018 at 1:42 AM, Alistair Grant <[hidden email]> 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 <[hidden email]> wrote:
>> > > Hi Alistair, Hi Cl??ment,
>> > >
>> > > On Fri, Jan 19, 2018 at 12:53 PM, Alistair Grant <[hidden email]>
>> > > wrote:
>> > >>
>> > >> Hi Cl??ment,
>> > >>
>> > >> On 19 January 2018 at 17:21, Alistair Grant <[hidden email]> wrote:
>> > >> > Hi Cl??ment,
>> > >> >
>> > >> > On 19 January 2018 at 17:04, Cl??ment Bera <[hidden email]>
>> > >> > 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
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

Stuart Cassoff-2
 
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 <[hidden email]>
> Date: January 23, 2018 at 3:24 AM
>
>
>  
> Hi Eliot,
>
> On 23 January 2018 at 01:47, Eliot Miranda <[hidden email]> wrote:
> >
> > Hi Alistair,
> >
> > On Mon, Jan 22, 2018 at 1:42 AM, Alistair Grant <[hidden email]> 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 <[hidden email]> wrote:
> >> > > Hi Alistair, Hi Cl??ment,
> >> > >
> >> > > On Fri, Jan 19, 2018 at 12:53 PM, Alistair Grant <[hidden email]>
> >> > > wrote:
> >> > >>
> >> > >> Hi Cl??ment,
> >> > >>
> >> > >> On 19 January 2018 at 17:21, Alistair Grant <[hidden email]> wrote:
> >> > >> > Hi Cl??ment,
> >> > >> >
> >> > >> > On 19 January 2018 at 17:04, Cl??ment Bera <[hidden email]>
> >> > >> > 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
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

alistairgrant
 
Hi Stu,

On 23 January 2018 at 16:15, Stuart Cassoff <[hidden email]> 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
--
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

Stuart Cassoff-2
 
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 <[hidden email]>
> Date: January 23, 2018 at 10:40 AM
>
>
> Hi Stu,
>
> On 23 January 2018 at 16:15, Stuart Cassoff <[hidden email]> 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
> --
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

alistairgrant
 
Hi Stu,

On 23 January 2018 at 21:33, Stuart Cassoff <[hidden email]> 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 <[hidden email]>
>> Date: January 23, 2018 at 10:40 AM
>>
>>
>> Hi Stu,
>>
>> On 23 January 2018 at 16:15, Stuart Cassoff <[hidden email]> 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
>> --

AKG-Corruption.st (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

timrowledge
 
> On 23 January 2018 at 21:33, Stuart Cassoff <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- All foam, no beer.


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

Stuart Cassoff-2
 
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 <[hidden email]>
> Date: January 24, 2018 at 1:37 PM
>
>
>  
> > On 23 January 2018 at 21:33, Stuart Cassoff <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
> Useful random insult:- All foam, no beer.
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

Stuart Cassoff-2
 
"...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 <[hidden email]>
> 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 <[hidden email]>
> > Date: January 24, 2018 at 1:37 PM
> >
> >
> >  
> > > On 23 January 2018 at 21:33, Stuart Cassoff <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
> > Useful random insult:- All foam, no beer.
> >
> >
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

alistairgrant
In reply to this post by Stuart Cassoff-2
 
On 24 January 2018 at 21:58, Stuart Cassoff <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

Stuart Cassoff-2
 
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 <[hidden email]>
> Date: January 24, 2018 at 4:04 PM
>
>
> On 24 January 2018 at 21:58, Stuart Cassoff <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

Ben Coman
In reply to this post by Stuart Cassoff-2
 
On 25 January 2018 at 05:04, Stuart Cassoff <[hidden email]> 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-smalltalk-pdf/ebook/product-18783337.html

cheers -ben

>
> Stu
>
>
>> ---------- Original Message ----------
>> From: Stuart Cassoff <[hidden email]>
>> 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 <[hidden email]>
>> > Date: January 24, 2018 at 1:37 PM
>> >
>> >
>> >
>> > > On 23 January 2018 at 21:33, Stuart Cassoff <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
>> > Useful random insult:- All foam, no beer.
>> >
>> >
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

Stuart Cassoff-2
In reply to this post by alistairgrant
 
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 <[hidden email]>
> Date: January 24, 2018 at 11:34 AM
>
>
> Hi Stu,
>
> On 23 January 2018 at 21:33, Stuart Cassoff <[hidden email]> 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 <[hidden email]>
> >> Date: January 23, 2018 at 10:40 AM
> >>
> >>
> >> Hi Stu,
> >>
> >> On 23 January 2018 at 16:15, Stuart Cassoff <[hidden email]> 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
> >> --
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

alistairgrant
In reply to this post by Stuart Cassoff-2
 
Hi Stu,

On 24 January 2018 at 22:24, Stuart Cassoff <[hidden email]> 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 <[hidden email]>
>> Date: January 24, 2018 at 4:04 PM
>>
>>
>> On 24 January 2018 at 21:58, Stuart Cassoff <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

Stuart Cassoff-2
In reply to this post by Ben Coman
 
Thanks!

> ---------- Original Message ----------
> From: Ben Coman <[hidden email]>
> Date: January 24, 2018 at 4:55 PM
>
>
> On 25 January 2018 at 05:04, Stuart Cassoff <[hidden email]> 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-smalltalk-pdf/ebook/product-18783337.html
>
> cheers -ben
>
> >
> > Stu
> >
> >
> >> ---------- Original Message ----------
> >> From: Stuart Cassoff <[hidden email]>
> >> 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 <[hidden email]>
> >> > Date: January 24, 2018 at 1:37 PM
> >> >
> >> >
> >> >
> >> > > On 23 January 2018 at 21:33, Stuart Cassoff <[hidden email]> 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; [hidden email]; http://www.rowledge.org/tim
> >> > Useful random insult:- All foam, no beer.
> >> >
> >> >
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

Stuart Cassoff-2
In reply to this post by alistairgrant
 
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 <[hidden email]>
> Date: January 24, 2018 at 4:04 PM
>
>
> On 24 January 2018 at 21:58, Stuart Cassoff <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

Stuart Cassoff-2
 
Silly me, I really should read the docs that come with. :/

> ---------- Original Message ----------
> From: Stuart Cassoff <[hidden email]>
> 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 <[hidden email]>
> > Date: January 24, 2018 at 4:04 PM
> >
> >
> > On 24 January 2018 at 21:58, Stuart Cassoff <[hidden email]> 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