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

[Linda A. Walsh]

Jonathan Wakely wrote:
> On 13/08/14 13:11 -0700, Linda A. Walsh wrote:
> 
> Did you read the link I gave? 
Yes -- and the one he based his statements on .

> You only needed to read the
> introduction. Just two sentences really:
----
Reading != complete and total reprogramming.


> "An lvalue is an expression that refers to a memory location and
> allows us to take the address of that memory location via the &
> operator. An rvalue is an expression that is not an lvalue."
> 
> http://thbecker.net/articles/rvalue_references/section_01.html
----
	Just because it has been redefined to be that,
apart from historical terminology, doesn't mean the old meaning doesn't
have meaning or validity.

a=b;

Calling both lvalue's obscures what is going on.

One is accessed only for it' value, one is assigned to.

The author and the source he refers to say that the previous
definition was fine for "C" and the new definition was needed
more for c++.

I can't look at an expression "a=b", and have simple terms
lvalue, rvalue, to refer to right hand value and the left hand destination
without resorting to longer phrases.  I took from the article that
there are situations where simply calling the right-hand expression
an r-value might obscure important details about what is going on,
but in this case, I think the usage clarifies what is going on.

I have written code where the expressions on both sides were(are)
lvalues,  and knowing that was important to understanding how the code
worked.  Ex: a utility routine that did some work using the fieldnum
and was followed by an increment of the fieldnum (or not).  Since the
increment of the field usually happened, but not always, it made sense
to have the util routine return an l-value to fieldnum, and the
caller could have a util()++  or no post-inc to move to the next field.

So, I think in this case the RHS is an lvalue used as an rvalue in the expression.

:-)  I'm guessing we both know what we are talking about, especially as related
to this statement?


>>> Could that be the problem?
>> ----
>>     The capacity is read in during program startup as the
>> maximum number of samples to store ..... so before the graph stuff or
>> routines to read the samples are ever called, that capacity is set.
> 
> OK, then samples[0] should be valid. I would still suggest changing it
> to samples.at(0) to be sure though.
---
That and the other change you mentioned...
I got sucked into another project for a bit, but maybe
can try some of these;   However, I'd already done some
refactoring to work around the error and it had already
gone "below surface"* when I got your 1st message.

*-below surface = programming I did got around the problem such that
is no longer happening -- but doesn't mean the underlying cause is
addressed yet and that it won't come back and bite later.


>