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 Monday, 21 October 2013 at 10:36:21 UTC, 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.

A conservative garbage collector is never "correct" according to Valgrind [0]. You need to configure Valgrind to ignore the GC. Here is an example for the Boehm GC: https://github.com/UU-ComputerScience/uhc/tree/master/EHC/misc/valgrind

[0] http://www.hpl.hp.com/hosted/linux/mail-archives/gc/2004-November/000629.html

Valgrind in its current state is unfortunately almost unusable with D as it does not support some instructions at least DMD emits.

On 21/10/13 14:04, Dicebot wrote:
> Valgrind in its current state is unfortunately almost unusable with D as it does
> not support some instructions at least DMD emits.

Don't know about DMD as I never use it for "production" apart from when I'm working on Phobos, but I've found some of the valgrind family quite useful in profiling D code (which I compile either with GDC or LDC).  Memcheck seems useful only in checking the overall number of allocs, though.

On 10/21/13 5:04 AM, Dicebot wrote:
> Valgrind in its current state is unfortunately almost unusable with D as it does not support some
> instructions at least DMD emits.

Are those issues in bugzilla (for either dmd or valgrind)?

On Monday, 21 October 2013 at 17:01:51 UTC, Brad Roberts wrote:
> On 10/21/13 5:04 AM, Dicebot wrote:
>> Valgrind in its current state is unfortunately almost unusable with D as it does not support some
>> instructions at least DMD emits.
>
> Are those issues in bugzilla (for either dmd or valgrind)?

http://d.puremagic.com/issues/show_bug.cgi?id=10054 for example. It is valgrind issue but I don't know if it was ever reported there.

On Monday, 21 October 2013 at 12:04:10 UTC, Dicebot wrote:
> Valgrind in its current state is unfortunately almost unusable with D as it does not support some instructions at least DMD emits.

This is widely wrong. Valgrind can catch many, many bugs, including wrong code, memory errors etc. It just reports warnings on some GC code (it seems that what makes valgrind suspicios is inline asm which initializes some stack data in gc) and sometimes it cannot recognize code instructions (in my experience somtimes means 2 cases of IR bugs for 2 years of debugging buggy code from bugzilla). Taking into account incomplete status of compiler it brings much value. Better description is not "almost unusable" but "failing in extreme cases due to IR bugs and giving some false pasitive conditional jump ... messages about GC code".

On Monday, 21 October 2013 at 21:26:14 UTC, Maxim Fomin wrote:
> On Monday, 21 October 2013 at 12:04:10 UTC, Dicebot wrote:
>> Valgrind in its current state is unfortunately almost unusable with D as it does not support some instructions at least DMD emits.
>
> This is widely wrong.

It is in fact true. I couldn't use it on x86_64 Linux to analyse/profile pretty much any non-trivial D application due to some floating point instructions DMD emits not being recognised. There wasn't even any esoteric code involved, just some floating point formatting or similar. Maybe it works fine for test cases from Bugzilla (but wouldn't you typically rather use it on DMD itself for those anyway?), but it's virtually unusable for real D applications. And I say that as a Valgrind fan, having also made some smaller contributions to KCachegrind, a cachegrind/callgrind result viewer for KDE.

GDC/LDC-produced executables work just fine, though.

David