• Stefan Rohe (52/52) Apr 22 2009 Hi,
• Sean Kelly (4/11) Apr 22 2009 The last time I looked into this, Valgrind was wrong about these
• Brad Roberts (12/26) Apr 22 2009 I spent a good looking at similar reports a few years ago. The cause,

"Stefan Rohe" <Stefan.Rohe funkwerk-itk.com> writes:

Hi,

has anybody experience with the usage of valgrind and D?
We are here using DMD (dmd 1.033/tango 0.997 but also some older versions)
and got problems using valgrind on this.
It seems that the _d_newarrayT routine or something under it jumps or moves
on unitialized value(s).
Same with the _adDupT and _d_arrayappendT-method, which all call the
_D3gcx3Gcx11fullcollectMFPvZk method.
Has anybody the same experiences? Is it a bug within the Compiler or should
be something avoided?


Stefan

[1] attached resource: valgrind-output
==19023== Conditional jump or move depends on uninitialised value(s)
==19023==    at 0x85273FF: _D3gcx3Gcx11fullcollectMFPvZk (in
/home/stefan/workspace/DDev/build/default/valgrindproject/test_executable)
==19023==    by 0x85270F9: _D3gcx3Gcx16fullcollectshellMFZk (in
/home/stefan/workspace/DDev/build/default/valgrindproject/test_executable)
==19023==    by 0x8525729: _D3gcx2GC12mallocNoSyncMFkkZPv (in
/home/stefan/workspace/DDev/build/default/valgrindproject/test_executable)
==19023==    by 0x8525646: _D3gcx2GC6mallocMFkkZPv (in
/home/stefan/workspace/DDev/build/default/valgrindproject/test_executable)
==19023==    by 0x85250B6: gc_malloc (in
/home/stefan/workspace/DDev/build/default/valgrindproject/test_executable)
==19023==    by 0x8523893: _d_newarrayT (in
/home/stefan/workspace/DDev/build/default/valgrindproject/test_executable)
==19023==    by 0x85201C1: _aaGet (in
/home/stefan/workspace/DDev/build/default/valgrindproject/test_executable)
==19023==    by 0x8546035:
_D5tango4text5Regex11__T4TDFATwZ4TDFA14epsilonClosureMFC5tango4text5Regex11_
_T4TDFATwZ4TDFA11SubsetStateC5tango4text5Regex11__T4TDFATwZ4TDFA11SubsetStat
eZC5tango4text5Regex11__T4TDFATwZ4TDFA11SubsetState15__foreachbody57MFKC5tan
go4text5Regex22__T14TNFATransitionTwZ14TNFATransitionZi (in
/home/stefan/workspace/DDev/build/default/valgrindproject/test_executable)
==19023==    by 0x8059513:
_D5tango4text5Regex68__T4ListTC5tango4text5Regex22__T14TNFATransitionTwZ14TN
FATransitionZ4List7opApplyMFDFKC5tango4text5Regex22__T14TNFATransitionTwZ14T
NFATransitionZiZi
(/home/stefan/workspace/DDev/dev_env/tango/dmd/include/tango/text/Regex.d:28
8)
==19023==    by 0x8545E52:
_D5tango4text5Regex11__T4TDFATwZ4TDFA14epsilonClosureMFC5tango4text5Regex11_
_T4TDFATwZ4TDFA11SubsetStateC5tango4text5Regex11__T4TDFATwZ4TDFA11SubsetStat
eZC5tango4text5Regex11__T4TDFATwZ4TDFA11SubsetState (in
/home/stefan/workspace/DDev/build/default/valgrindproject/test_executable)
==19023==    by 0x8544AC7:
_D5tango4text5Regex11__T4TDFATwZ4TDFA5_ctorMFC5tango4text5Regex11__T4TNFATwZ
4TNFAZC5tango4text5Regex11__T4TDFATwZ4TDFA (in
/home/stefan/workspace/DDev/build/default/valgrindproject/test_executable)
==19023==    by 0x854294B:
_D5tango4text5Regex14__T7RegExpTTaZ7RegExpT5_ctorMFAabbbZC5tango4text5Regex1
4__T7RegExpTTaZ7RegExpT (in
/home/stefan/workspace/DDev/build/default/valgrindproject/test_executable)

Sean Kelly <sean invisibleduck.org> writes:

Stefan Rohe wrote:
 Hi,
 
 has anybody experience with the usage of valgrind and D?
 We are here using DMD (dmd 1.033/tango 0.997 but also some older versions)
 and got problems using valgrind on this.
 It seems that the _d_newarrayT routine or something under it jumps or moves
 on unitialized value(s).

The last time I looked into this, Valgrind was wrong about these 
cases--initialization is actually logically guaranteed.  You can check 
for yourself though.  See lib/compiler/dmd/lifetime.d.

Brad Roberts <braddr puremagic.com> writes:

Sean Kelly wrote:
 Stefan Rohe wrote:
 Hi,

 has anybody experience with the usage of valgrind and D?
 We are here using DMD (dmd 1.033/tango 0.997 but also some older
 versions)
 and got problems using valgrind on this.
 It seems that the _d_newarrayT routine or something under it jumps or
 moves
 on unitialized value(s).

 
 The last time I looked into this, Valgrind was wrong about these
 cases--initialization is actually logically guaranteed.  You can check
 for yourself though.  See lib/compiler/dmd/lifetime.d.

I spent a good looking at similar reports a few years ago.  The cause,
at the time, was that the gc code walks the stack(s) during collections
and has to examine every stack slot since it has no way of knowing
anything about which slots are valid and which aren't.  Valgrind, on the
other hand, does know what stack slots have been assigned values and
which haven't so can accurately report that the program has looked at
memory that hasn't been initialized yet.  One 'fix' might be to
pre-initialize the stack with 0's upon function entry.  I'm not even
terribly convinced that'd work.

Later,
Brad