[Python-Dev] valgrind reports

[Neal Norwitz]

This was run on linux amd64.  It would be great to run purify on
windows and other platforms.  If you do, please report back here, even
if nothing was found.  That would be a good data point.

Summary of tests with problems:

test_codecencodings_jp (1 invalid read)
test_coding (1 invalid read)
test_ctypes (crashes valgrind)
test_socket_ssl (many invalid reads)
test_sqlite (1 invalid read, 1 memory leak)

Details:

New one:
test_codecencodings_jp
==19749==
==19749== Invalid read of size 1
==19749==    at 0xE4F7BB3: shift_jis_2004_decode (_codecs_jp.c:642)
==19749==    by 0xE1AD8D5: decoder_feed_buffer (multibytecodec.c:839)
==19749==    by 0xE1ADCEB: mbidecoder_decode (multibytecodec.c:1028)
==19749==    by 0x46875C: call_function (ceval.c:3637)
==19749==  Address 0x5E0DD63 is 0 bytes after a block of size 3 alloc'd
==19749==    at 0x4A19AC6: malloc (vg_replace_malloc.c:149)
==19749==    by 0xE1ADD7F: mbidecoder_decode (multibytecodec.c:1017)
==19749==    by 0x46875C: call_function (ceval.c:3637)

I think this is the same as:  http://python.org/sf/1357836

test_coding
==19749==
==19749== Invalid read of size 1
==19749==    at 0x4135DF: tok_nextc (tokenizer.c:901)
==19749==    by 0x413BE5: tok_get (tokenizer.c:1124)
==19749==    by 0x4145D8: PyTokenizer_Get (tokenizer.c:1515)
==19749==    by 0x411F12: parsetok (parsetok.c:135)
==19749==    by 0x481051: PyParser_ASTFromFile (pythonrun.c:1318)
==19749==  Address 0xC6E1EE6 is 2 bytes before a block of size 8,192 free'd
==19749==    at 0x4A1A61D: free (vg_replace_malloc.c:235)
==19749==    by 0x4125BC: error_ret (tokenizer.c:167)
==19749==    by 0x412D34: decoding_fgets (tokenizer.c:513)
==19749==    by 0x4134B0: tok_nextc (tokenizer.c:841)
==19749==    by 0x413BE5: tok_get (tokenizer.c:1124)
==19749==    by 0x4145D8: PyTokenizer_Get (tokenizer.c:1515)
==19749==    by 0x411F12: parsetok (parsetok.c:135)

test_ctypes crashes valgrind on amd64: 
http://bugs.kde.org/show_bug.cgi?id=125651

test_socket_ssl causes all kinds of havoc due to libssl.  I don't know
of any problems specific to Python.  It would be good for others to
test on different architectures.

test_sqlite
==22745== Invalid read of size 4
==22745==    at 0x6B94D01: sqlite3VdbeFinalize (vdbeaux.c:1457)
==22745==    by 0x6B7B24F: sqlite3_finalize (main.c:1304)
==22745==    by 0x6858646: statement_dealloc (statement.c:300)
==22745==    by 0x6854EAE: connection_call (connection.c:759)
==22745==    by 0x419287: call_function_tail (abstract.c:1799)
==22745==    by 0x4193AF: PyObject_CallFunction (abstract.c:1854)
==22745==    by 0x685364C: cache_get (cache.c:170)
==22745==    by 0x6856181: _query_execute (cursor.c:545)
==22745==  Address 0x53FE38C is 148 bytes inside a block of size 696 free'd
==22745==    at 0x4A1A61D: free (vg_replace_malloc.c:235)
==22745==    by 0x6B8C39D: sqlite3FreeX (util.c:287)
==22745==    by 0x6B94EB7: sqlite3VdbeDelete (vdbeaux.c:1524)
==22745==    by 0x6B94D2D: sqlite3VdbeFinalize (vdbeaux.c:1462)
==22745==    by 0x6B7B24F: sqlite3_finalize (main.c:1304)
==22745==    by 0x6857F8B: statement_create (statement.c:82)
==22745==    by 0x6854E67: connection_call (connection.c:748)

==22796== 8 bytes in 1 blocks are definitely lost in loss record 21 of 545
==22796==    at 0x4A19AC6: malloc (vg_replace_malloc.c:149)
==22796==    by 0x6854A21: connection_set_isolation_level (connection.c:721)
==22796==    by 0x6854C40: connection_init (connection.c:81)


n