Question

I have a template class defined as:

#include <stdio.h>
#include <queue>

using namespace std;

template<class T>
class tbufferpool {
private:
    const int m_initial;
    const int m_size;
    const int m_total;
    T *m_buffer;
    vector<T*> m_queue;

public:
    // constructor
    tbufferpool(int initial, int size) : m_initial(initial), m_size(size), m_total(initial*size) {
        m_buffer = new T[m_total];
        T* next_buffer = m_buffer;
        for (int i = 0; i < initial; ++i, next_buffer += size) {
            m_queue.push_back(next_buffer);
        }
    }

and at some point in the constructor I do:

m_buffer = new T[size];

This works for most use-cases but in one test I get the following memory error reported by valgrind (command and relevant snippet below) the test still passes fine though. The interesting bit is operator new(unsigned long) meaning it is not allocating and aligning for the concrete T type I setup “double” as I expected but for unsigned long? If I modify my bufferpool implementation and hard-code new double[size] then this memory error doesn’t show but of course I only work with tbufferpool<double> now.

Can anyone advice how to fix this? the new T[size] should be legal right? since the template parameters is applied at compile time by the pre-processor that creates a new class for each template type used. Would this be a compiler bug?

The test_matrix is a suite containing 30 test cases. Only one test produces the problem shown below in valgrind, that test passes nevertheless. I checked all the inputs to the function call where the problem originates using the new T[size] variant and printed them alongside the same inputs using new double[size] variant. I compare them using AraxisMerge and they are identical. I’m afraid is a problem related to the memory alignment turning out different depending whether I use the template parameter or the concrete double type … ?

$ valgrind --show-reachable=yes --dsymutil=yes --track-origins=yes ./test_matrix
  [snip]
  ==3719== Conditional jump or move depends on uninitialised value(s)
  ==3719==    at 0x3BE86C8: mkl_blas_dscal (in /opt/intel/composerxe-2011.4.184/mkl/lib/libmkl_mc3.dylib)
  ==3719==    by 0x432FFFFFFFFFFFFF: ???
  ==3719==  Uninitialised value was created by a heap allocation
  ==3719==    at 0xD62F: malloc (vg_replace_malloc.c:266)
  ==3719==    by 0x97B15C: operator new(unsigned long) (in /opt/local/lib/gcc46/libstdc++.6.dylib)
  ==3719==    by 0x7FFF5FBFE54F: ???
  ==3719==    by 0x10014BDBF: ???
  ==3719==    by 0x7FFF5FBFE58F: ???
  ==3719==    by 0x97B288: operator new[](unsigned long) (in /opt/local/lib/gcc46/libstdc++.6.dylib)
  ==3719==    by 0x7FFF5FBFE58F: ???
  ==3719==    by 0x100013853: tbufferpool<double>::tbufferpool(int, int) (bufferpool.h:30)
  ==3719==    by 0x7003FFFFF: ???
  ==3719==    by 0x100079E7F: ??? (in ./test_matrix)
  ==3719==    by 0x7FFF5FBFE58F: ???
  ==3719==    by 0x10014BE0F: ???
  ==3719== 
  ==3719== Conditional jump or move depends on uninitialised value(s)
  ==3719==    at 0x3BE86CA: mkl_blas_dscal (in /opt/intel/composerxe-2011.4.184/mkl/lib/libmkl_mc3.dylib)
  ==3719==    by 0x432FFFFFFFFFFFFF: ???
  ==3719==  Uninitialised value was created by a heap allocation
  ==3719==    at 0xD62F: malloc (vg_replace_malloc.c:266)
  ==3719==    by 0x97B15C: operator new(unsigned long) (in /opt/local/lib/gcc46/libstdc++.6.dylib)
  ==3719==    by 0x7FFF5FBFE54F: ???
  ==3719==    by 0x10014BDBF: ???
  ==3719==    by 0x7FFF5FBFE58F: ???
  ==3719==    by 0x97B288: operator new[](unsigned long) (in /opt/local/lib/gcc46/libstdc++.6.dylib)
  ==3719==    by 0x7FFF5FBFE58F: ???
  ==3719==    by 0x100013853: tbufferpool<double>::tbufferpool(int, int) (bufferpool.h:30)
  ==3719==    by 0x7003FFFFF: ???
  ==3719==    by 0x100079E7F: ??? (in ./test_matrix)
  ==3719==    by 0x7FFF5FBFE58F: ???
  ==3719==    by 0x10014BE0F: ???
  [snip]

System details:

/Users/bravegag/code/fastcode_project/build_debug$ uname -a && g++ --version
Darwin Macintosh-4.local 11.3.0 Darwin Kernel Version 11.3.0: Thu Jan 12 18:47:41 PST 2012; 
root:xnu-1699.24.23~1/RELEASE_X86_64 x86_64
g++ (GCC) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Answer 1

Please note the difference between

m_buffer = new T[size];

and

m_buffer = new T[size]();

In the former case the array is not initialised, hence your valgrind error:

Conditional jump or move depends on uninitialised value

That said, from my experience you can ignore this particular valgrind output in this case. As you obviously use some kind of blas implementation, most likely it is the effect of an optimisation inside your BLAS library and won’t do bad things.