Re: [Bug-apl] Mismatched free( )/delete/delete [ ], invalid read of 4 bytes, & uninitialized values

[Juergen Sauermann]

Dear Fred,

ad 1)
the delete is actually correct. the Cells to which the pointer points 
have beed destructed before
and delete[] would lead to double destruction. I have inserted a 
variable long_ravel in Value.cc which
hopefully confuses valgrind enough to not complain anymore.

ad 2)
I have changed that as you proposed, SVN 111.

ad 3)
I have changed that as you proposed, SVN 111.

And yes, I am interested in bringing down the number of memory leaks.

Best Regards,
Jürgen


On 01/27/2014 10:30 PM, Frederick H. Pitts wrote:
> Gentle people,
>
>         valgrind runs with options --leak-check=full --show-leak-kinds=all
> --track-origins=yes --read-var-info=yes against Gnu APL, svn rev. 107,
> reveals the following:
>
>         1) 'new' invocation on line Value.cc:103 needs to be paired with a
> 'delete []' invocation on line Value.cc:347, not just 'delete'.
>
>         2) invalid read of 4 bytes on line Value.hh:481 results from the
> pointer to deleted memory not being zeroed.  That zeroing will occur if
> the 'delete v;' on line Value.hh:513 is replaced with '{ delete v; v =
> 0; }' and 'v' declared with 'Value *&' rather than 'Value *' on lines
> Value.hh:492 and SharedValuePointer.hh:34.
>
>         3) "conditional jump or move depends on uninitialised value(s)" error
> on line Tokenizer.cc:587 results from 'real_flt' and 'real_int' being
> declared but not initialized on line Tokenizer.cc:513 and 514. These two
> variables are ultimately set by sscanf calls on lines Tokenizer.cc:655
> and 656.  If either sscanf call returns 0, the corresponding variable is
> not set.  Initializing 'real_flt' and 'real_int' to 0. and 0 eliminates
> this error.
>
>         Admittedly, none of the above edits change the results Gnu APL
> produces, but they do reduce the amount of clutter one has to sort
> through to find malignant memory leaks and errors using valgrind.  The
> first two errors were occurring numerous times in a given run.
>
>         Are you interested in trying to reduce the amount of unrecovered memory
> on a normal shutdown to near zero bytes.  I believe most projects do not
> bother because the end user does not see any immediate benefit from the
> effort.  On the other hand, if developers want to stay on top of memory
> leaks by detecting them early, its beneficial to have a near zero
> unrecovered memory number rather than a large number that masks the
> appearance of new leaks.
>
> Regards,
>
> Fred Pitts
> Retired Chemical Engineer