Garbage collector collects live objects
Steven Schveighoffer via Digitalmars-d-learn
digitalmars-d-learn at puremagic.com
Tue Dec 9 11:56:30 PST 2014
On 12/9/14 12:40 PM, Ruslan Mullakhmetov wrote:
> On Tuesday, 9 December 2014 at 16:13:25 UTC, Dicebot wrote:
>> It may happen if only reference to an object is stored in memory block
>> marked as data-only (using ubyte[] for a buffer is probably most
>> common reason I have encountered)
>
> Thanks for interesting hypothesis, but that's not the issue.
>
> innocent though collected objects are living in D array MyClass[] which
> are living in assoc array as value.
>
> i checked attributes for GC block holding this array:
>
> ```
> FINALIZE NO_SCAN NO_MOVE APPENDABLE NO_INTERIOR
> ```
>
That does not sound right at all. No block should ever have both
FINALIZE (reserved for objects only) and APPENDABLE (reserved for arrays
only).
> I really doubting about NO_INTERIOR. can anybody confirm me that is's
> working with array slicing which i heavily use?
>
>
> also i found that block size is quite small
>
> <pre>
> array: [100A2FD00, 100A2F700, 100A33B80, 100A33500,
> 100A3FE80, 100A3F980, 100A3F400, 100A72600, 100A7DF80, 100A7DA80,
> 100A7D500]
> array ptr: 100A72580 root: 100A72580:128 attr: FINALIZE NO_SCAN
> NO_MOVE APPENDABLE NO_INTERIOR
> [100985A00] keys: [1] as: 1 au: 100A2FD00
> [100985A00] keys: [1] as: 1 au: 100A2F700
> [100985A00] keys: [1] as: 1 au: 100A33B80
> </pre>
>
> array holds 11 64bit pointers but it's block size is only 128 bytes < 11
> * 64 = 704 bytes. what's wrong with this arithmetics?
>
I think there is something you are missing, or something is very
corrupt. Can you show the code that prints this?
-Steve
More information about the Digitalmars-d-learn
mailing list