[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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4