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

Jonathan Wakely
Wed Aug 13 09:59:00 GMT 2014

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:
>fields_sz=3, vals=2147483636,2147483637,2147483637,
>col_samp_dat_sz=3, vals=2147483630,2147483637,2147483637,
>vals=2147483620,2147483637,2147483637,...doesn't stop.
>When in vg it looks normal:
>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

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?

More information about the Libc-help mailing list