<div dir="ltr">Hi Alistair,<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 22, 2018 at 1:42 AM, Alistair Grant <span dir="ltr"><<a href="mailto:akgrant0710@gmail.com" target="_blank">akgrant0710@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Hi Eliot,<br>
<span class=""><br>
On Sat, Jan 20, 2018 at 09:19:04AM +0100, Alistair Grant wrote:<br>
> Hi Eliot,<br>
><br>
> On 19 January 2018 at 23:04, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
</span>> > Hi Alistair, Hi Cl??ment,<br>
<span class="">> ><br>
> > On Fri, Jan 19, 2018 at 12:53 PM, Alistair Grant <<a href="mailto:akgrant0710@gmail.com">akgrant0710@gmail.com</a>><br>
> > wrote:<br>
> >><br>
</span>> >> Hi Cl??ment,<br>
<span class="">> >><br>
> >> On 19 January 2018 at 17:21, Alistair Grant <<a href="mailto:akgrant0710@gmail.com">akgrant0710@gmail.com</a>> wrote:<br>
</span>> >> > Hi Cl??ment,<br>
> >> ><br>
> >> > On 19 January 2018 at 17:04, Cl??ment Bera <<a href="mailto:bera.clement@gmail.com">bera.clement@gmail.com</a>><br>
<span class="">> >> > wrote:<br>
> >> >> Does not seem to be related to prim 105.<br>
> >> >><br>
> ><br>
> ><br>
> > I suspect that the problem is the same compactor bug I've been trying to<br>
> > reproduce all week, and have just fixed.  Could you try and reproduce with a<br>
> > VM built from the latest commit?<br>
><br>
> Happy to, but I'm out all day today, so it will be tomorrow or Monday.<br>
><br>
> Cheers,<br>
> Alistair<br>
> (on the run...)<br>
<br>
<br>
</span>I've tested this with 2 images and 3 VMs in all 6<br>
combinations:<br>
<br>
- "Old VM":   commit date: Wed Jan 10 23:39:30 2018 -0800, gcc 4.8.5<br>
- "New VM":   commit date: Sat Jan 20 13:52:26 2018 +0100, gcc 4.8.5<br>
- "GCC 5 VM": commit date: Sat Jan 20 13:52:26 2018 +0100, gcc 5.4.0<br>
- Clean image: commit id: b28d466f<br>
- Work image:  commit id: eb0a6fb1<br>
<br>
The gcc 5 is only there because I was playing with it.  The results may<br>
be useful, or completely misleading. :-)<br>
<br>
Each time I ran "5 timesRepeat: [ self test4 ]"<br>
with the halts replaced with a count increment.<br>
test4 is the method provided in Cyrille's original message.<br>
<br>
Result summary:<br>
<br>
- Old VM + Work image:  5, 5, 5, 0, 0<br>
- Old VM + Clean image: 5, 5, 0, 0, 0<br>
- New VM + Work image:  5, 0, 5, 5, 5<br>
- New VM + Clean image: 0, 0, 1, 5, 5<br>
- GCC 5 + Work image:   0, 0, 0, 0, 0<br>
- GCC 5 + Clean image:  0, 0, 0, 0, 0<br></blockquote><div><br></div><div>This is strong evidence for the issue being a compiler bug with 4.8.x</div><div>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.</div><div>Assuming it is a gcc bug then</div><div>- it should be documented in the HowToBuild files for the relevant platforms</div><div>- Ci builds should start using gcc 5 and dispense with gcc 4.8.x</div><div>- 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</div><div><br></div><div>What's the status of the bug on Windows and Mac OS X?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Old VM:<br>
<span class="">5.0-201801110739  Thursday 11 January  09:30:12 CET 2018 gcc 4.8.5 [Production Spur VM]<br>
CoInterpreter VMMaker.oscog-eem.2302 uuid: 55ec8f63-cdbe-4e79-8f22-<wbr>48fdea585b88 Jan 11 2018<br>
StackToRegisterMappingCogit VMMaker.oscog-eem.2302 uuid: 55ec8f63-cdbe-4e79-8f22-<wbr>48fdea585b88 Jan 11 2018<br>
VM: 201801110739 alistair@alistair-xps13:snap/<wbr>pharo-snap/pharo-vm/<wbr>opensmalltalk-vm $ Date: Wed Jan 10 23:39:30 2018 -0800 $<br>
Plugins: 201801110739 alistair@alistair-xps13:snap/<wbr>pharo-snap/pharo-vm/<wbr>opensmalltalk-vm $<br>
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<br>
</span>plugin path: /snap/pharo7/x1/usr/bin/pharo-<wbr>vm32/ [default: /snap/pharo7/x1/usr/bin/pharo-<wbr>vm32/]<br>
<br>
<br>
<br>
New VM:<br>
5.0-201801201252  Saturday 20 January  21:24:16 CET 2018 gcc 4.8.5 [Production Spur VM]<br>
CoInterpreter VMMaker.oscog-eem.2320 uuid: e2692e35-5fc8-4623-95d0-<wbr>b445b3329f75 Jan 20 2018<br>
StackToRegisterMappingCogit VMMaker.oscog-eem.2320 uuid: e2692e35-5fc8-4623-95d0-<wbr>b445b3329f75 Jan 20 2018<br>
VM: 201801201252 alistair@d62ce50f4930:snap/<wbr>pharo-snap/pharo-vm/<wbr>opensmalltalk-vm $ Date: Sat Jan 20 13:52:26 2018 +0100 $<br>
Plugins: 201801201252 alistair@d62ce50f4930:snap/<wbr>pharo-snap/pharo-vm/<wbr>opensmalltalk-vm $<br>
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<br>
plugin path: /snap/pharo7/x1/usr/bin/pharo-<wbr>vm32/ [default: /snap/pharo7/x1/usr/bin/pharo-<wbr>vm32/]<br>
<br>
<br>
<br>
GCC 5 VM:<br>
5.0-201801201252  Sun Jan 21 14:41:41 UTC 2018 gcc 5.4.0 [Production Spur VM]<br>
CoInterpreter VMMaker.oscog-eem.2320 uuid: e2692e35-5fc8-4623-95d0-<wbr>b445b3329f75 Jan 21 2018<br>
StackToRegisterMappingCogit VMMaker.oscog-eem.2320 uuid: e2692e35-5fc8-4623-95d0-<wbr>b445b3329f75 Jan 21 2018<br>
VM: 201801201252 alistair@alistair-xps13:<wbr>squeak/opensmalltalk-vm $ Date: Sat Jan 20 13:52:26 2018 +0100 $<br>
Plugins: 201801201252 alistair@alistair-xps13:<wbr>squeak/opensmalltalk-vm $<br>
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<br>
plugin path: /home/alistair/squeak/<wbr>opensmalltalk-vm/products/<wbr>phcogspurlinuxht/lib/pharo/5.<wbr>0-201801201252 [default: /home/alistair/squeak/<wbr>opensmalltalk-vm/products/<wbr>phcogspurlinuxht/lib/pharo/5.<wbr>0-201801201252/]<br>
<br>
<br>
HTH,<br>
Alistair<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
> > Some details:<br>
> > The SpurPlanningCompactor works by using the fact that all Spur objects have<br>
> > room for a forwarding pointer.  The compactor make three passes:<br>
> ><br>
> > - the first pass through memory works out where objects will go, replacig<br>
> > their first fields with where they will go, and saving their first fields in<br>
> > a buffer (savedFirstFieldsSpace).<br>
> > - the second pass scans all pointer objects, replacing their fields with<br>
> > where the objects referenced will go (following the forwarding pointers),<br>
> > and also relocates any pointer fields in savedFirstFieldsSpace<br>
> > - the final pass slides objects down, restoring their relocated first fields<br>
> ><br>
> > The buffer used for savedFirstFieldsSpace determines how many passes are<br>
> > used.  The system will either use eden (which is empty when compaction<br>
> > occurs) or a large free chunk or allocate a new segment, depending on<br>
> > whatever yields the largest space.  So in the right circumstances eden will<br>
> > be used and more than one pass required.<br>
> ><br>
> > The bug was that when multiple passes are used the compactor forgot to<br>
> > unmark the corpse left behind when the object was moved.  Instead of the<br>
> > corpse being changed into free space it was retained, but its first field<br>
> > would be that of the forwarding pointer to its new location, not the actual<br>
> > first field.  So on 32-bits a ByteArray that should have been collected<br>
> > would have its first 4 bytes appear to be invalid, and on 64-bits its first<br>
> > 8 bytes.  Because the heap on 64-bits can grow larger it could be that the<br>
> > bug shows itself much less frequently than on 32-bits. When compaction can<br>
> > be completed in a single pass all corpses are correctly collected, so most<br>
> > of the time the bug is hidden.<br>
> ><br>
> > This is the commit:<br>
> > commit 0fe1e1ea108e53501a0e7287360480<wbr>62c83a66ce<br>
> > Author: Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>><br>
> > Date:   Fri Jan 19 13:17:57 2018 -0800<br>
> ><br>
> >     CogVM source as per VMMaker.oscog-eem.2320<br>
> ><br>
> >     Spur:<br>
> >     Fix a bad bug in SpurPlnningCompactor.<br>
> > unmarkObjectsFromFirstFreeObje<wbr>ct,<br>
> >     used when the compactor requires more than one pass due to insufficient<br>
> >     savedFirstFieldsSpace, expects the corpse of a moved object to be<br>
> > unmarked,<br>
> >     but copyAndUnmarkObject:to:bytes:<wbr>firstField: only unmarked the target.<br>
> >     Unmarking the corpse before the copy unmarks both.  This fixes a crash<br>
> > with<br>
> >     ReleaseBuilder class>>saveAsNewRelease when non-use of cacheDuring:<br>
> > creates<br>
> >     lots of files, enough to push the system into the multi-pass regime.<br>
> ><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>