Re: [Python-Dev] Python under valgrind
Probably because of the object memory allocator. It reads the start of memory pages to see if a block belongs tot the obmalloc system or not. You want to remove the following line: #define WITH_PYMALLOC 1 From pyconfig.h if you intend to run using valgrind or say, purify. K -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Hrvoje Niksic Sent: 28. nóvember 2008 13:52 Cc: Python-Dev Subject: Re: [Python-Dev] Python under valgrind Amaury Forgeot d'Arc wrote: Did you use the suppressions file as suggested in Misc/README.valgrind? Thanks for the suggestion (as well as to Gustavo and Victor), but my question wasn't about how to suppress the messages, but about why the messages appear in the first place. I think my last paragraph answers my own question, but I'm not sure. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/kristjan%40ccpgames.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python under valgrind
A friend pointed out that running python under valgrind (simply valgrind python) produces a lot of invalid read errors. Reading up on Misc/README.valgrind only seems to describe why uninitialized reads should occur, not invalid ones. For example: $ valgrind python [... lots of output ...] ==31428== Invalid read of size 4 ==31428==at 0x808EBDF: PyObject_Free (in /usr/bin/python2.5) ==31428==by 0x810DD0A: (within /usr/bin/python2.5) ==31428==by 0x810DD34: PyNode_Free (in /usr/bin/python2.5) ==31428==by 0x80EDAD9: PyRun_InteractiveOneFlags (in /usr/bin/python2.5) ==31428==by 0x80EDDB7: PyRun_InteractiveLoopFlags (in /usr/bin/python2.5) ==31428==by 0x80EE515: PyRun_AnyFileExFlags (in /usr/bin/python2.5) ==31428==by 0x80595E6: Py_Main (in /usr/bin/python2.5) ==31428==by 0x8058961: main (in /usr/bin/python2.5) ==31428== Address 0x43bf010 is 3,112 bytes inside a block of size 6,016 free'd ==31428==at 0x4024B4A: free (vg_replace_malloc.c:323) ==31428==by 0x8059C07: (within /usr/bin/python2.5) ==31428==by 0x80EDAA5: PyRun_InteractiveOneFlags (in /usr/bin/python2.5) ... valgrind claims that Python reads 4 bytes inside a block on which free() has already been called. Is valgrind wrong, or is Python really doing that? Googling revealed previous reports of this, normally answered by a reference to README.valgrind. But README.valgrind justifies reading from ununitialized memory, which doesn't help me understand how reading from the middle of a block of freed memory (more precisely, memory on which the libc free() has already been called) would be okay. I suppose valgrind could be confused by PyFree's pool address validation that intentionally reads the memory just before the allocated block, and incorrectly attributes it to a previously allocated (and hence freed) block, but I can't prove that. Has anyone investigated this kind of valgrind report? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python under valgrind
Le Friday 28 November 2008 13:56:34 Amaury Forgeot d'Arc, vous avez écrit : Hrvoje Niksic wrote: A friend pointed out that running python under valgrind (simply valgrind python) produces a lot of invalid read errors. (...) PyFree (...) Did you use the suppressions file as suggested in Misc/README.valgrind? --suppressions=Misc/valgrind-python.supp To be able to use the suppressions, Python have to be compiled with Py_USING_MEMORY_DEBUGGER. Edit Object/obmalloc.c near line 680. -- Victor Stinner aka haypo http://www.haypocalc.com/blog/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python under valgrind
2008/11/28 Hrvoje Niksic [EMAIL PROTECTED] A friend pointed out that running python under valgrind (simply valgrind python) produces a lot of invalid read errors. Reading up on Misc/README.valgrind only seems to describe why uninitialized reads should occur, not invalid ones. For example: $ valgrind python [... lots of output ...] ==31428== Invalid read of size 4 ==31428==at 0x808EBDF: PyObject_Free (in /usr/bin/python2.5) ==31428==by 0x810DD0A: (within /usr/bin/python2.5) ==31428==by 0x810DD34: PyNode_Free (in /usr/bin/python2.5) ==31428==by 0x80EDAD9: PyRun_InteractiveOneFlags (in /usr/bin/python2.5) ==31428==by 0x80EDDB7: PyRun_InteractiveLoopFlags (in /usr/bin/python2.5) ==31428==by 0x80EE515: PyRun_AnyFileExFlags (in /usr/bin/python2.5) ==31428==by 0x80595E6: Py_Main (in /usr/bin/python2.5) ==31428==by 0x8058961: main (in /usr/bin/python2.5) ==31428== Address 0x43bf010 is 3,112 bytes inside a block of size 6,016 free'd ==31428==at 0x4024B4A: free (vg_replace_malloc.c:323) ==31428==by 0x8059C07: (within /usr/bin/python2.5) ==31428==by 0x80EDAA5: PyRun_InteractiveOneFlags (in /usr/bin/python2.5) ... valgrind claims that Python reads 4 bytes inside a block on which free() has already been called. Is valgrind wrong, or is Python really doing that? Googling revealed previous reports of this, normally answered by a reference to README.valgrind. But README.valgrind justifies reading from ununitialized memory, which doesn't help me understand how reading from the middle of a block of freed memory (more precisely, memory on which the libc free() has already been called) would be okay. I suppose valgrind could be confused by PyFree's pool address validation that intentionally reads the memory just before the allocated block, and incorrectly attributes it to a previously allocated (and hence freed) block, but I can't prove that. Has anyone investigated this kind of valgrind report? I can't answer your question directly, but I can tell you that whenever I have to debug memory problems with python extensions is usually use my own python compiled with --with-pydebug --without-pymalloc. It really helps with valgrind. -- Gustavo J. A. M. Carneiro INESC Porto, Telecommunications and Multimedia Unit The universe is always one step beyond logic. -- Frank Herbert ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python under valgrind
Hrvoje Niksic wrote: A friend pointed out that running python under valgrind (simply valgrind python) produces a lot of invalid read errors. Reading up on Misc/README.valgrind only seems to describe why uninitialized reads should occur, not invalid ones. For example: [...] I suppose valgrind could be confused by PyFree's pool address validation that intentionally reads the memory just before the allocated block, and incorrectly attributes it to a previously allocated (and hence freed) block, but I can't prove that. Has anyone investigated this kind of valgrind report? Did you use the suppressions file as suggested in Misc/README.valgrind? --suppressions=Misc/valgrind-python.supp -- Amaury Forgeot d'Arc ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python under valgrind
I suppose valgrind could be confused by PyFree's pool address validation that intentionally reads the memory just before the allocated block, and incorrectly attributes it to a previously allocated (and hence freed) block, but I can't prove that. I agree this is the likely cause. To prove it, you will need to find the line number associated with 0x808EBDF. Either you available debug information, or disassemble PyObject_Free to determine what specific read operation is causing the report. Most likely, you find it is inside Py_ADDRESS_IN_RANGE, in the attempt to read pool-arenaindex. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
