Add loop.c -- a test program for repeatedly calling Py_Initialize()

and Py_Finalize().  It seems to dump core right now...

Demo/embed/Makefile

@@ -32,13 +32,20 @@ all:		demo
 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

Demo/embed/README

@@ -10,3 +10,10 @@ the source directory (../..)
 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.

Demo/embed/loop.c

+/* 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*/
+}