This wasn't used with Python. I started with modifying the client.c file included in gambit/tests and proceeded from there. I'll check on commenting out the call to release_fn soon.
Thanks Marc,
-Dave
On Wed, Jan 12, 2011 at 8:36 AM, Marc Feeley feeley@iro.umontreal.ca wrote:
On 2011-01-12, at 8:17 AM, David Dreisigmeyer wrote:
It could be the call to ___release_foreign (in c_intf.c) that's causing the trouble. The calling sequence is:
___cleanup (setup.c) => ___cleanup_mem (mem.c) => free_still_objs (mem.c) => ___release_foreign (c_intf.c)
With this (modified) snippet from free_still_objs:
As far as I know, in the unmodified Gambit, there are no foreign objects with release functions. So I don't understand why you get release_fn != NULL. So if you comment out the call to the release_fn, does the problem go away?
Commenting out the call to ___cleanup_mem in ___cleanup, the code still fails on ___cleanup_os. Here it seems to have something to do with ___device_group_cleanup in os_io.c. Now the call sequence is:
___cleanup (setup.c) => ___cleanup_os (os.c) => ___cleanup_io_module (os_io,c) => io_module_cleanup (os_io,c) => ___device_group_cleanup (os_io.c)
Here it seems to be a problem with the line:
if (___device_cleanup (dgroup->list) != ___FIX(___NO_ERR))
It would be interesting to know which device is failing to cleanup properly. My hunch is that Python is closing a file descriptor or changing an attribute of the file descriptor that Gambit expects to be in a particular state when it cleans up, so when it tries to close it (or call select on it), a failure is reported. The failure will happen in one of the ___device_XXX_close_raw_virt functions in lib/os_io.c or lib/os_tty.c (most probably in ___device_file_close_raw_virt or ___device_tty_close_raw_virt).
Marc