• Artem Tarasov (38/38) Oct 21 2013 There seems to be some serious issue with the GC, yet almost no attentio...
• qznc (7/17) Oct 21 2013 A conservative garbage collector is never "correct" according to
• Dicebot (3/3) Oct 21 2013 Valgrind in its current state is unfortunately almost unusable
• Joseph Rushton Wakeling (5/7) Oct 21 2013 Don't know about DMD as I never use it for "production" apart from when ...
• Brad Roberts (2/4) Oct 21 2013 Are those issues in bugzilla (for either dmd or valgrind)?
• Dicebot (4/9) Oct 21 2013 http://d.puremagic.com/issues/show_bug.cgi?id=10054 for example.
• Maxim Fomin (11/14) Oct 21 2013 This is widely wrong. Valgrind can catch many, many bugs,
• David Nadlinger (13/18) Oct 21 2013 It is in fact true. I couldn't use it on x86_64 Linux to

Artem Tarasov <lomereiter gmail.com> writes:

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)

"qznc" <qznc web.de> writes:

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

"Dicebot" <public dicebot.lv> writes:

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

Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:

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.

Brad Roberts <braddr puremagic.com> writes:

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)?

"Dicebot" <public dicebot.lv> writes:

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.

"Maxim Fomin" <maxim maxim-fomin.ru> writes:

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".

"David Nadlinger" <code klickverbot.at> writes:

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