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
>
>
>
