[Python-Dev] Valgrinding Python

[Tim Peters]

[Oren Tirosh]
> I ran some tests with Julian Seward's amazing Valgrind memory debugger.
> Python is remarkably clean.  Much cleaner than any other program of
> non-trivial size that I tested.

It's been thru Purify and Insure++, off and on, several times, and we
enjoyed many wasted hours squashing suprious complaints from those <wink>.

> Objects/obmalloc.c:
>
>    The ADDRESS_IN_RANGE macro makes references to uninitialized memory.
>
> This produced tons of warnings so I ran the rest of the tests without
> pymalloc.

Ouch.  That's not going to change, so it may be worth learning how to write
a Valgrind suppression file.  ADDRESS_IN_RANGE determines whether an address
was passed out by pymalloc.  It does this by (a) reading an index from an
address computed *from* the claimant address; then (b) using that to index
into its own data structures, which record the range of addresses pymalloc
controls; then (c) comparing the claimant address to that range.  Part #a
can easily end up reading uninitialized memory. but pymalloc doesn't care (a
junk value found there can't fool it).  This is needed to determine whether
to hand off an address to the platform free() or realloc(), and in such
cases part #a may well read up any kind of trash.

> The following tests produced invalid accesses inside the external
> library:
>
> test_anydbm.py
> test_bsddb.py
> test_dbm.py
> test_gdbm.py
> test_curses.py
> test_pwd.py
> test_socket_ssl.py

Figures <wink>.

> I also got some invalid accesses in
> Modules/arraymodule.c:array_ass_subscr
> while running test_array and in Objects/Listobject.c:list_ass_subscript
> running test_types. For some reason I couldn't reproduce them later.

Another memory-debugging tool, another chance to debug a memory-debugging
tool.