On 2010-03-11 05:32, Stephen Lucas wrote:
When this occurs, I am unable to load any more abstractions (dynamically or manually) but I am able to create regular objects. However, it is always accompanied by an inability to save, which produces the error:
error: (save path): Bad file descriptor
sounds to me like the famous file-handle leak on w32. could you try to run the task manager, enable the display of "number of handles" column in the "processes" tab, and watch it rise whenever you create an object.
The only way to fix this is to restart pd and hope that I don't lose much unsaved work.
I'm fairly certain that this is a GEM related issue, since I have used the same technique to instantiate thousands of non-GEM abstractions without this problem. I have not tested to see if the problem happens by creating 70+ instances manually; however, it is definitely cumulative and the problem eventually happens despite clearing and remaking only a few instances.
i have no real idea where this happens; the file-handle leak is known to occur on w32 when opening e.g. images; is your dynamically-instantiated abstraction doing something like this?
all of the above should be true for both dynamic and manual patching.
anyhow, it would still be nice to have a minimal patch exposing the problem (with minimal dependencies as well: only Pd-vanilla and Gem)
the problem is really the way how windows handles file handles: a file opened in one dll (in our case: pd), can eventually be _not_ closed in another dll (in our case: Gem). the only solution that i know of, would involve Pd offering a possibility to also close the handle.
mfgasdr IOhannes