Garbage collector collects live objects

Ruslan Mullakhmetov via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Fri Dec 12 04:52:58 PST 2014


On Thursday, 11 December 2014 at 18:36:59 UTC, Steven 
Schveighoffer wrote:
> My analysis so far:
>
> 2. In the array append code, the block attributes are obtained 
> via GC.query, which has this code for getting the attributes:
>
> https://github.com/D-Programming-Language/druntime/blob/master/src/gc/gc.d#L1792
>
> Quoting from that function:
>
> // reset the offset to the base pointer, otherwise the bits
> // are the bits for the pointer, which may be garbage
> offset = cast(size_t)(info.base - pool.baseAddr);
> info.attr = getBits(pool, cast(size_t)(offset >> pool.shiftBy));
>
> Which should get the correct bits. I suspected there was an 
> issue with getting the wrong bits, but this code looks correct.
>
> 3. The runtime caches the block info for thread local data for 
> append speed. A potential issue is that the attributes are 
> cached from a previous use for that block, but the GC (and the 
> runtime itself) SHOULD clear that cache entry when that block 
> is freed, avoiding this issue. A potential way to check this is 
> to assert in a debug build of druntime that the cached block 
> info always equals the actual block info. Are you able to build 
> a debug version of druntime to test this? I can give you the 
> changes you should make. This would explain the great 
> difficulty in reproducing the issue.

I will try to build debug version of dmd compiler and check the 
issue.

>
> 4. If your code is multi-threaded, but using __gshared, it can 
> make the cache incorrect. Are you doing this?
>

the app is multi-threaded via std.concurrency.

there is only one known to me place where __gshared is used: 
logging library (checked by searching through whole source tree). 
make stub for this lib and try, so identify whether cache 
invalidated by _gshared or not.

> But the cache is really the only possible place I can see where 
> the bits are set incorrectly, given that you just verified the 
> bits are correct before the append.
>
> Can you just list the version of the compiler you are using? I 
> want to make sure this isn't an issue that has already been 
> fixed.

the last. first of all i updated whole toolchain (dmd, dub).

$ dmd
DMD64 D Compiler v2.066.1

> -Steve

I started looking druntime and dmd source code myself before i 
checked the thread (thsnks for your help and feedback) and i have 
some questions. could you explain to me something?

i_m looking here 
https://github.com/D-Programming-Language/druntime/blob/v2.066.1/src/rt/lifetime.d#L591

-------
line #603
auto size = ti.next.tsize;

why `next`? it can be even null if this is last TypeInfo in the 
linked list.

---------

btw, i used suggested trackallocs.d and GC defenetely receives 
NO_SCAN

before tag: 1 len: 2 ptr: 103A78058 root: 103A77000:8192 attr: 
APPENDABLE
gc_qalloc(41, NO_SCAN APPENDABLE ) cc: 29106 asz: 10152603, ti: 
null ret: BlkInfo_(104423800, 64, 10)
after tag: 1 len: 3 ptr: 104423810 root: 104423800:64 attr: 
NO_SCAN APPENDABLE


More information about the Digitalmars-d-learn mailing list