strange problem in libc: free invalid pointer, but valgrind doesn't show it.

[Jonathan Wakely]

On 12/08/14 03:01 -0700, Linda A. Walsh wrote:
>I added a call to the print statement before the assignment.
>
>When not in vg, it gets ugly:
>FMG:rfrsh:sc(0)<W(696);sw={0/1;1},s/c={0/1;1}
>fields_sz=3, vals=2147483636,2147483637,2147483637,
>col_samp_dat_sz=3, vals=2147483630,2147483637,2147483637,
>samples[0].D_sz=-1162167622, 
>vals=2147483620,2147483637,2147483637,...doesn't stop.
>
>When in vg it looks normal:
>
>FMG:rfrsh:sc(0)<W(696);sw={0/1;1},s/c={0/1;1}
>fields_sz=3, vals=2147483636,2147483637,2147483637,
>col_samp_dat_sz=3, vals=2147483630,2147483637,2147483637,
>samples[0].D_sz=0, vals=
>samples[0].D_sz=3, vals=2147483630,2147483637,2147483637,
>---
>
>So it looks like it doesn't like me assigning to a val array not of the
>same size?  But it works on vg?
>
>I have an idea of how to work around this, but shouldn't the
>l-value "array" pick up it's size from the r-value "array"  (C++ valarray)?

There's no rvalue on line 295, but yes, the size of the target will
be adjusted to the required size before copying the elements from the
source.

The error happens inside valarray<T>::operator(const valarray<T>&)
when freeing the old storage of the target object (which in your case
is samples[0].D). The pointer that object owns is clearly invalid:

 *** Error in `./xosview': free(): invalid pointer: 0xbabababababababa ***

So my best guess is that samples[0].D was never initialized, or was
already freed. Is samples just a block of uninitialized memory that
has never had constructors run for its elements?