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

[Frederick H. Pitts]

Gentle people,

        [I'm resending this email because I left the `[Bug-apl]' prefix off the
the subject line in the previous email.  Also I've added some additional
valgrind detected memory errors.]

        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'. The
same concept applies to the delete's at file_io:cc:597, 617 and 643.

        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.

        3a) "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.

        3b) The same kind of error is reported on line Archive.cc:1024 because
'current_char' is not initialized before its first use. 'current_char'
should be initialized in the XML_Loading_Archive constructor member
initializer list (along with every other class member).

        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 project
teams 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