While I haven't re-examined this issue in years, the collector hasn't changed and this property continues to hold... it's a natural artifact of the stack scan process in the gc.  Not every byte of the stack is initialized from valgrind's point of view (or in reality), yet the stack scan can't know that and takes every slot into account regardless.  IE, it's a standard part of conservative gc engines.  The right 'solution' is to suppress that stacktrace in valgrind.

On 10/21/13 3:36 AM, Artem Tarasov wrote:
> There seems to be some serious issue with the GC, yet almost no attention is paid to that.
> (See e.g. this thread: http://forum.dlang.org/thread/anhitkodvlstehwxasld@forum.dlang.org)
>
> I did a simple test: `void main { new ubyte[65536]; }`. This doesn't pass memcheck!
> Valgrind tells about using uninitialized values in core.thread.callWithStackShell called by
> gc.gcx.Gcx.mark.
>
> Can anybody look into that?
>
> ==3595== Conditional jump or move depends on uninitialised value(s)
> ==3595==    at 0x41E605: _D2gc3gcx3Gcx4markMFPvPviZv (in /home/lomereiter/test)
> ==3595==    by 0x41E5B7: _D2gc3gcx3Gcx4markMFPvPvZv (in /home/lomereiter/test)
> ==3595==    by 0x425520:
> _D4core6thread14thread_scanAllUMDFPvPvZvZv45__T10__lambda69TE4core6thread8ScanTypeTPvTPvZ10__lambda69MFE4core6thread8ScanTypePvPvZv
> (in /home/lomereiter/test)
> ==3595==    by 0x4291DA: _D4core6thread15scanAllTypeImplFMDFE4core6thread8ScanTypePvPvZvPvZv (in
> /home/lomereiter/test)
> ==3595==    by 0x429140:
> _D4core6thread18thread_scanAllTypeUMDFE4core6thread8ScanTypePvPvZvZv19__T10__lambda62TPvZ10__lambda62MFPvZv
> (in /home/lomereiter/test)
> ==3595==    by 0x42900F: _D4core6thread18callWithStackShellFMDFPvZvZv (in /home/lomereiter/test)
> ==3595==    by 0x429118: thread_scanAllType (in /home/lomereiter/test)
> ==3595==    by 0x4254F8: thread_scanAll (in /home/lomereiter/test)
> ==3595==    by 0x41EAA5: _D2gc3gcx3Gcx11fullcollectMFZm (in /home/lomereiter/test)
> ==3595==    by 0x41E05C: _D2gc3gcx3Gcx8bigAllocMFmPPS2gc3gcx4PoolPmZPv (in /home/lomereiter/test)
> ==3595==    by 0x41B983: _D2gc3gcx2GC12mallocNoSyncMFmkPmZPv (in /home/lomereiter/test)
> ==3595==    by 0x41B7B6: _D2gc3gcx2GC6mallocMFmkPmZPv (in /home/lomereiter/test)
> ==3595==  Uninitialised value was created by a stack allocation
> ==3595==    at 0x428FE0: _D4core6thread18callWithStackShellFMDFPvZvZv (in /home/lomereiter/test)
>

On Mon, Oct 21, 2013 at 9:00 PM, Brad Roberts <braddr@puremagic.com> wrote:

> While I haven't re-examined this issue in years, the collector hasn't changed and this property continues to hold... it's a natural artifact of the stack scan process in the gc.  Not every byte of the stack is initialized from valgrind's point of view (or in reality), yet the stack scan can't know that and takes every slot into account regardless.  IE, it's a standard part of conservative gc engines.  The right 'solution' is to suppress that stacktrace in valgrind.
>

Makes sense. Thanks for the explanation, Brad.