[issue7632] dtoa.c: oversize b in quorem, and a menagerie of other bugs

[Mark Dickinson]

Mark Dickinson <dickinsm at gmail.com> added the comment:

Stefan, thanks for that!  I'm not entirely sure how to make use of it, though.  Is there a way to tell Valgrind that some leaks are expected?

The main problem with leak detection is that dtoa.c deliberately keeps hold of any malloc'ed chunks less than a certain size (which I think is something like 2048 bytes, but I'm not sure).  These chunks are never freed in normal use;  instead, they're added to a bunch of free lists for the next time that strtod or dtoa is called.  The logic isn't too complicated:  it's in the functions Balloc and Bfree in dtoa.c.

So the right thing to do is just to check that for each call to strtod, the total number of calls to Balloc matches the total number of calls to Bfree with non-NULL argument.  And similarly for dtoa, except that in that case one of the Balloc'd blocks gets returned to the caller (it's the caller's responsibility to call free_dtoa to free it when it's no longer needed), so there should be a difference of 1.

And there's one further wrinkle:  dtoa.c maintains a list of powers of 5 of the form 5**2**k, and this list is automatically extended with newly allocated Bigints when necessary:  those Bigints are never freed either, so calls to Balloc from that source should be ignored.  Another way round this is just to ignore any leak from the first call to strtod, and then do a repeat call with the same parameters;  the second call will already have all the powers of 5 it needs.

----------

_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue7632>
_______________________________________