[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-apl] Mismatched free( )/delete/delete [ ], invalid read of 4 by

From: Juergen Sauermann
Subject: Re: [Bug-apl] Mismatched free( )/delete/delete [ ], invalid read of 4 bytes, & uninitialized values
Date: Tue, 28 Jan 2014 16:41:17 +0100
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130330 Thunderbird/17.0.5

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,

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.


Fred Pitts
Retired Chemical Engineer

reply via email to

[Prev in Thread] Current Thread [Next in Thread]