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