common lisp - How to track and isolate filehandler leaks -

common lisp - How to track and isolate filehandler leaks -

i running in error while running programme (though never opening /dev/null)

couldn't open "/dev/null": many open files

i assume leaking filehandlers @ point. not using raw open or close with-open-file , sb-ex:process-close process create sb-ext:run-prgram confused. not know leaking pointless post code much copy-paste , random samples wont help either.

therefore, how can track filehandlers , isolate leaks?

this separate lisp program, , rather background issue on system. because mention /dev/null, sounds you're on flavor of unix, , lsof might help in tracking downwards what's still open. error messages aren't sbcl specific, typical searched help find general answers, though of investigation techniques may relevant. since haven't posted sbcl code, it's hard provide sbcl specific responses. (but maybe there sbcl specific profiling tools. there disconnect between calls letting file descriptors closed, , sbcl closing them.

now, though sounds you're using mutual lisp apis correctly, there surprising border cases. sure you're not holding references them anywhere maintain them getting released? global list somewhere, or, doing things in repl *, **, , *** variables hold past results, contribute.

now, alternative implementation might still have file descriptors open, if mutual lisp stream closed. with-open-file binds stream you, , that's implementation's wrapper around file descriptor. (i'd surprised if sbcl leaking that, though.) instance, if output hasn't been flushed, might file descriptor stays around while. using force-output or clear-output might help of issues.

common-lisp sbcl