I'm seeing Valgrind errors when importing Pandas. This Python is built with --with-valgrind, which disables PyMalloc when running under valgrind. The Pandas version was pulled from Github just now, but this issue happens with 0.10 also.
~$ valgrind python -c 'import sys'
==2832== Memcheck, a memory error detector
==2832== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==2832== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==2832== Command: python -c import\ sys
==2832==
==2832==
==2832== HEAP SUMMARY:
==2832== in use at exit: 864,491 bytes in 5,240 blocks
==2832== total heap usage: 42,287 allocs, 37,047 frees, 9,519,928 bytes allocated
==2832==
==2832== LEAK SUMMARY:
==2832== definitely lost: 0 bytes in 0 blocks
==2832== indirectly lost: 0 bytes in 0 blocks
==2832== possibly lost: 281,296 bytes in 1,031 blocks
==2832== still reachable: 583,195 bytes in 4,209 blocks
==2832== suppressed: 0 bytes in 0 blocks
==2832== Rerun with --leak-check=full to see details of leaked memory
==2832==
==2832== For counts of detected and suppressed errors, rerun with: -v
==2832== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 7)
~$ valgrind python -c 'import pandas'
==2981== Memcheck, a memory error detector
==2981== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==2981== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==2981== Command: python -c import\ pandas
==2981==
==2981== Invalid read of size 4
==2981== at 0x442ECF: long_new (longobject.c:3998)
==2981== by 0x466262: type_call (typeobject.c:721)
==2981== by 0x4189BC: PyObject_Call (abstract.c:2529)
==2981== by 0x49715C: PyEval_EvalFrameEx (ceval.c:4239)
==2981== by 0x49DD7A: PyEval_EvalCodeEx (ceval.c:3253)
==2981== by 0x49B701: PyEval_EvalFrameEx (ceval.c:4117)
==2981== by 0x49DD7A: PyEval_EvalCodeEx (ceval.c:3253)
==2981== by 0x4FCA3E: function_call (funcobject.c:526)
==2981== by 0x4189BC: PyObject_Call (abstract.c:2529)
==2981== by 0x41FECE: instancemethod_call (classobject.c:2578)
==2981== by 0x4189BC: PyObject_Call (abstract.c:2529)
==2981== by 0x46CFF7: slot_tp_init (typeobject.c:5663)
==2981== Address 0xc8f1764 is 68 bytes inside a block of size 69 alloc'd
==2981== at 0x4C238B8: malloc (vg_replace_malloc.c:270)
==2981== by 0x4501D3: PyObject_Malloc (obmalloc.c:943)
==2981== by 0x457CA5: PyString_FromStringAndSize (stringobject.c:88)
==2981== by 0xF2E6457: binascii_hexlify (binascii.c:1075)
==2981== by 0x49C8C1: PyEval_EvalFrameEx (ceval.c:4021)
==2981== by 0x49DD7A: PyEval_EvalCodeEx (ceval.c:3253)
==2981== by 0x49B701: PyEval_EvalFrameEx (ceval.c:4117)
==2981== by 0x49DD7A: PyEval_EvalCodeEx (ceval.c:3253)
==2981== by 0x4FCA3E: function_call (funcobject.c:526)
==2981== by 0x4189BC: PyObject_Call (abstract.c:2529)
==2981== by 0x41FECE: instancemethod_call (classobject.c:2578)
==2981== by 0x4189BC: PyObject_Call (abstract.c:2529)
==2981==
==2981==
==2981== HEAP SUMMARY:
==2981== in use at exit: 10,613,864 bytes in 73,317 blocks
==2981== total heap usage: 586,122 allocs, 512,805 frees, 90,175,227 bytes allocated
==2981==
==2981== LEAK SUMMARY:
==2981== definitely lost: 245 bytes in 3 blocks
==2981== indirectly lost: 0 bytes in 0 blocks
==2981== possibly lost: 3,140,920 bytes in 24,857 blocks
==2981== still reachable: 7,472,699 bytes in 48,457 blocks
==2981== suppressed: 0 bytes in 0 blocks
==2981== Rerun with --leak-check=full to see details of leaked memory
==2981==
==2981== For counts of detected and suppressed errors, rerun with: -v
==2981== ERROR SUMMARY: 2 errors from 1 contexts (suppressed: 202 from 10)
~$ python -c 'import pandas; print pandas.version.version'
0.11.0.dev-14a04dd
Comment From: wesm
I get valgrind errors like that when I do valgrind python
Comment From: csakhil
I did the "import sys" to demonstrate that I don't see any valgrind errors when doing non-Pandas work.
Did you build your version of Python using "--with-valgrind"?
Comment From: wesm
Someone should take a look somday to see where the valgrind errors are coming from and if it's caused by bad pandas code. Probably one of the Cython extensions
Comment From: ghost
I chased this down some. 99% of the warnings are in init* boilerplate code generated by cython, which I promptly ignored.
Warnings that reference specific pyx code all look pretty innocent to me. a couple of hits on objects allocated during import, pretty sure those are false positives, one warning associated with a call in Timestamp to _Timestamp.new, which looks fine to me as pyx, I verified that creating a Timestamp object in user code does not create a valgrind warning, so if this isn't a false-positive, it's limited to the
_CACHE_START = Timestamp(datetime(1950, 1, 1))
_CACHE_END = Timestamp(datetime(2030, 1, 1))
module globals in tseries/index.py
None of the warnings that are flagged "definitely" lost reference any pandas c files.
Trace gist for 19577969, if someone else wants to have a look. This is against cpython with --with-valgrind --enable-unicode=ucs4
Comment From: wesm
If someone is interested in this, it would be good to look into on a more recent pandas version