---------- Forwarded message ----------
From: Eliot Miranda <[hidden email]>
Date: Fri, Jan 19, 2018 at 2:04 PM
Subject: Re: [Pharo-dev] Random corrupted data when copying from very large byte array
To: Pharo Development List <[hidden email]>
Hi Alistair, Hi Clément,
On Fri, Jan 19, 2018 at 12:53 PM, Alistair Grant <[hidden email]> wrote:
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?
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:
Author: Eliot Miranda <[hidden email]>
Date: Fri Jan 19 13:17:57 2018 -0800
CogVM source as per VMMaker.oscog-eem.2320
Fix a bad bug in SpurPlnningCompactor.
used when the compactor requires more than one pass due to insufficient
savedFirstFieldsSpace, expects the corpse of a moved object to be unmarked,
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.
I'll try it as soon as I can figure out
where that VM might be.
On 1/19/18 5:05 PM, Eliot Miranda wrote:
On Sat, 20 Jan 2018 at 3:47 pm, Bob Arning <[hidden email]> wrote:
I hope to have a VM pre-release ready sometime next week, so you could try one of those once announced.
|Free forum by Nabble||Edit this page|