[Lapackpp-devel] bugs in reference counting in vd.{cc,h}?

[Brian W. <bw...@cs...>]

> Yes, that's true and it's a feature :-) .

Thanks for the explanation, Christian.

I may have another bug.  I can't pinpoint exactly what the problem is, but
I can manifest it repeatedly and I can fix it. :)

I've included a program called manifestMemProb.C, which is similar to the
last program I sent out.  It creates two different views of a matrix (plus
the original) and modifies them.  It does the same procedure on a
different matrix.  Somehow, the second matrix is being corrupted, as you
can see in the file manifestMemProb.incorrect.

Like I said, I was unable to track down the exact problem.  It may be
related to new'ing and delete'ing 0 byte chunks of memory?  I added a
check for n=0 in the following constructor:

VectorDouble::VectorDouble(int n=0)

In that case, I set ref_count = 0 and p->data = data = NULL:

 VectorDouble::VectorDouble(int n=0)
{
    assert(n>=0);
    p = new vrefDouble;
    p->sz = n;
    if ( n > 0 ) {
      p->data = data = new double[n];
      p->ref_count = 1;
    } else {
      p->data = data = NULL;
      p->ref_count = 0;
    }
}

I then only decremented ref_count if it was > 0.  And asserted explicitly
that p->data was non-NULL before delete'ing it.  However, even in the
original code this assertion was never hit.  At any rate, this seems to
have fixed the manifestation of the bug.  Sorry I can't provide a better
understanding of what was going on.

I ended up changing all of the constructors to do something similar.  I
also changed the VectorDouble destructor and ref (where ref_count is
decremented) as described above.  Also, in ref I don't increment the
ref_count unless the associated data is non-NULL.  In short then:
ref_counts are only > 0 when data != NULL.  Also, I never allocate or free
0-byte data.

I imagine other vectors will have the same type of problems, but I didn't
fix those.

I'm sending my modified vd.cc and vd.h.

By the way, please let me know if I'm somehow abusing the interface in my
example such that I am causing the seemingly incorrect behavior.

Thanks,
Brian