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

[Jonathan Wakely <jwakely at redhat dot com>]

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?