A
Anders Wegge Keller
During the final test of a bit of embedded python, I wanted to see if
I had any hanging references. To my suprise, I ended up with a rather
large amount, after running combinerefs.py. And even with the
simplest[1] possible use of embedding, I end up with 13475 still-living
references.
If this is the expected case, then what are the possible benefit from
running a process with the PYTHONDUMPREFS ebvironment variable set? My
code would have to be hemorrhaging in a severe way, to show up on this
background. Am I missing something here?
The system in question is a Fedora 19 Linux, using the distribution's
Python3 debug rpm. I've seen similar results with Python 2.6, just at
a lesser scale.
1:
#include <stdlib.h>
#include <Python.h>
int main (int argc, char **argv) {
Py_Initialize();
Py_Finalize();
return EXIT_SUCCESS;
}
Compiled with:
gcc pyleak.c -o pyleak `/usr/bin/python3.3dm-config --cflags` \
`/usr/bin/python3.3dm-config --ldflags`
I had any hanging references. To my suprise, I ended up with a rather
large amount, after running combinerefs.py. And even with the
simplest[1] possible use of embedding, I end up with 13475 still-living
references.
If this is the expected case, then what are the possible benefit from
running a process with the PYTHONDUMPREFS ebvironment variable set? My
code would have to be hemorrhaging in a severe way, to show up on this
background. Am I missing something here?
The system in question is a Fedora 19 Linux, using the distribution's
Python3 debug rpm. I've seen similar results with Python 2.6, just at
a lesser scale.
1:
#include <stdlib.h>
#include <Python.h>
int main (int argc, char **argv) {
Py_Initialize();
Py_Finalize();
return EXIT_SUCCESS;
}
Compiled with:
gcc pyleak.c -o pyleak `/usr/bin/python3.3dm-config --cflags` \
`/usr/bin/python3.3dm-config --ldflags`