Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.python > #77984 > unrolled thread

Properly Using 3.4.1 & Valgrind

Started byJeremy Moles <cubicool@gmail.com>
First post2014-09-17 15:45 -0700
Last post2014-09-17 22:08 -0700
Articles 2 — 1 participant

Back to article view | Back to comp.lang.python


Contents

  Properly Using 3.4.1 & Valgrind Jeremy Moles <cubicool@gmail.com> - 2014-09-17 15:45 -0700
    Re: Properly Using 3.4.1 & Valgrind Jeremy Moles <cubicool@gmail.com> - 2014-09-17 22:08 -0700

#77984 — Properly Using 3.4.1 & Valgrind

FromJeremy Moles <cubicool@gmail.com>
Date2014-09-17 15:45 -0700
SubjectProperly Using 3.4.1 & Valgrind
Message-ID<4a65eb8d-4fba-400a-81bc-ee029c2a8f66@googlegroups.com>
Hey guys. I'm using the Python 3.4.1 release tarball, and am trying to configure it for usage with valgrind. I have followed all of the common, well-documented steps online such as uncommenting Py_USING_MEMORY_DEBUGGER, compiling with --with-pydebug, --with-valgrind, and --without-pymalloc. I've tried uncommenting everything in the provided suppression file, as well.

However, no matter what I do with my configuration/build, I cannot get Python to stop reporting thousands of lines of leaks. In fact, every call to Py_MALLOC results in valgrind believing a leak has occurred, so you can imagine there would be a legion of errors just firing up the interpreter.

What is the modern, accepted way of using Python3 with valgrind, and what should my expectations be? I really like relying on Valgrind as an additional source of informative debugging information (though not exclusively), and any help resolving this would be appreciated.

At a minimum, I'd expect simply opening/closing the interpreter to generate no leak warnings. I'm perfectly fine making suppression files for small issues here or there (especially in libraries/modules), but I find it hard to believe a project as well-maintained as Python has this many "valid" leaks. I'm pretty sure the problem is me. :)

Thanks!

[toc] | [next] | [standalone]


#77998

FromJeremy Moles <cubicool@gmail.com>
Date2014-09-17 22:08 -0700
Message-ID<d304b289-9b1d-461e-b54f-9be2e0859c12@googlegroups.com>
In reply to#77984
On Wednesday, September 17, 2014 6:46:21 PM UTC-4, Jeremy Moles wrote:
> Hey guys. I'm using the Python 3.4.1 release tarball, and am trying to configure it for usage with valgrind. I have followed all of the common, well-documented steps online such as uncommenting Py_USING_MEMORY_DEBUGGER, compiling with --with-pydebug, --with-valgrind, and --without-pymalloc. I've tried uncommenting everything in the provided suppression file, as well.
> 
> 
> 
> However, no matter what I do with my configuration/build, I cannot get Python to stop reporting thousands of lines of leaks. In fact, every call to Py_MALLOC results in valgrind believing a leak has occurred, so you can imagine there would be a legion of errors just firing up the interpreter.
> 
> 
> 
> What is the modern, accepted way of using Python3 with valgrind, and what should my expectations be? I really like relying on Valgrind as an additional source of informative debugging information (though not exclusively), and any help resolving this would be appreciated.
> 
> 
> 
> At a minimum, I'd expect simply opening/closing the interpreter to generate no leak warnings. I'm perfectly fine making suppression files for small issues here or there (especially in libraries/modules), but I find it hard to believe a project as well-maintained as Python has this many "valid" leaks. I'm pretty sure the problem is me. :)
> 
> 
> 
> Thanks!

I would also like to add that I've tried building the newest valgrind from today's SVN, and have also had a hand at manually forcing normal malloc usage in Python. Neither of those changed anything, so I've reverted back to standard 3.4.1 for now.

[toc] | [prev] | [standalone]


Back to top | Article view | comp.lang.python


csiph-web