Tx for the bug entries!!!
I sort of doubt Magma uses anything registering external objects but the standard Sockets⦠While interrupting finalization process _could_ be a culprit, I'd rather watch for something like what happened with the InputEventFetcher, where registration/deregistration ends up not being symmetric.
Perhaps Magma tries to reuse existing Socket instances by calls to initialize:/acceptFrom: for example?
I think changing ExternalSemaphoreTable to a weak structure would be a really bad idea btw. All of a sudden, you free up slots which were previously taken for insertion of old objects.
There is no guarantee the external user of the semaphore will stop using the index it was given just because the image no longer holds a reference to the object which used to occupy that index.
So if you register a new object in the same slot, in the case of Sockets at least, you could potentially end up responding to signals from both the old external user, and the new one.
TLDR; Any object registered in this table by definition needs explicit cleanup of external users before they are GC'd. Thus, making the table weak makes no sense.
Yes, that could happen. Well, then the only option is to check what code producing leaks. And that's not trivial, since you cannot trace references back to semaphore's original owner. :(
-- Best regards, Igor Stasenko.
It's not such a big task to review the current users, there are like 5 of them in the base image.
AFAICT: 1) InputEventFetcher, this has been bug-fixed once already. No leaks as long as it has a single entry in startup/shutdown lists. 2) Sockets, which, to my knowledge work OK with the weak finalization. 3) AsyncFile, only done correctly if #close'd at EOL. No weak cleanup done it seems, could be changed to work like Sockets. 4) StandardFileStream url opening, should be modified to use an ensure: block. Only applicable when running in a browser though, unlikely to be a large issue. 5) NetNameResolver, never unregisters the semaphore, and leaks one whenever network needs (re)initialization. Snapshot? Image quit? Arbitrary points during execution? Reading the plugin source would tell the real cases I guess. A probable culprit in this case, I would say.
I opened http://code.google.com/p/pharo/issues/detail?id=5310 , which contains proposed changes related to 3-5.
I also opened 2 additional issues for things I ran into, but didn't do as it wasn't worth the effort/strictly related:
5311: Rewrite AsyncFile to have weak finalization for guaranteed cleanup of external objects 5312: Move StandardFileStream browserRequest protocol functionality to a separate package, and deprecate the protocol itself. The main purpose of the methods in this protocol has nothing to do with FileStreams, but rather performing navigation in a Browser when Pharo is run as a plugin.
Cheers, Henry