Add loop.c -- a test program for repeatedly calling Py_Initialize()
and Py_Finalize(). It seems to dump core right now...
diff --git a/Demo/embed/Makefile b/Demo/embed/Makefile
index fb2b1ed..ee0196b 100644
--- a/Demo/embed/Makefile
+++ b/Demo/embed/Makefile
@@ -32,13 +32,20 @@
demo: demo.o
$(CC) $(LDFLAGS) demo.o $(ALLLIBS) -o demo
+loop: loop.o
+ $(CC) $(LDFLAGS) loop.o $(ALLLIBS) -o loop
+
# Administrative targets
test: demo
./demo
+COMMAND="print 'hello world'"
+looptest: loop
+ ./loop $(COMMAND)
+
clean:
-rm -f *.o core
clobber: clean
- -rm -f *~ @* '#'* demo
+ -rm -f *~ @* '#'* demo loop
diff --git a/Demo/embed/README b/Demo/embed/README
index 8858c71..a0f7af8 100644
--- a/Demo/embed/README
+++ b/Demo/embed/README
@@ -10,3 +10,10 @@
2) change the variables that together define the list of libraries
(MODLIBS, LIBS, SYSLIBS) to link with, to match their definitions in
$(blddir)/Modules/Makefile
+
+An additional test program, loop.c, is used to experiment with memory
+leakage caused by repeated initialization and finalization of the
+interpreter. It can be build by saying "make loop" and tested with
+"make looptest". Command line usage is "./loop <python-command>",
+e.g. "./loop 'print 2+2'" should spit out an endless number of lines
+containing the number 4.
diff --git a/Demo/embed/loop.c b/Demo/embed/loop.c
new file mode 100644
index 0000000..ca89cb7
--- /dev/null
+++ b/Demo/embed/loop.c
@@ -0,0 +1,26 @@
+/* Simple program that repeatedly calls Py_Initialize(), does something, and
+ then calls Py_Finalize(). This should help finding leaks related to
+ initialization. */
+
+#include "Python.h"
+
+main(int argc, char **argv)
+{
+ char *command;
+
+ if (argc != 2) {
+ fprintf(stderr, "usage: loop <python-command>\n");
+ exit(2);
+ }
+
+ command = argv[1];
+
+ Py_SetProgramName(argv[0]);
+
+ while (1) {
+ Py_Initialize();
+ PyRun_SimpleString(command);
+ Py_Finalize();
+ }
+ /*NOTREACHED*/
+}