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

[Frederick H. Pitts]

Hello Jrgen,

        With regard to item 1:

a) I've rerun the valgrind test against SVN 111 and valgrind still
complains.

b) Before I suggested adding the '[]' to the 'delete', I made the change
and performed the valgrind test.  Valgrind did not complain about double
deletions.  It is possible the APL program I'm using does not contain
code that triggers the double deletion.  Can you point me to or send me
APL code that triggers the double deletion if 'delete []' is used?

        Also, please be aware that I've email'd a modified version of the
original email that points out additional places where valgrind detects
new/delete mismatches and a uninitialized value.

Regards,

Fred


On Tue, 2014-01-28 at 16:41 +0100, Juergen Sauermann wrote:
> 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
> >
> >
> >
> >
> >
>