Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.python > #77984 > unrolled thread
| Started by | Jeremy Moles <cubicool@gmail.com> |
|---|---|
| First post | 2014-09-17 15:45 -0700 |
| Last post | 2014-09-17 22:08 -0700 |
| Articles | 2 — 1 participant |
Back to article view | Back to comp.lang.python
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
| From | Jeremy Moles <cubicool@gmail.com> |
|---|---|
| Date | 2014-09-17 15:45 -0700 |
| Subject | Properly 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]
| From | Jeremy Moles <cubicool@gmail.com> |
|---|---|
| Date | 2014-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