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

[Frederick H. Pitts]

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