Socket handle leak and active handle warning with Vibe-D

Selim Ozel sozel at wpi.edu
Sat Jan 2 17:52:31 UTC 2021


On Saturday, 2 January 2021 at 00:28:43 UTC, Steven Schveighoffer 
wrote:
> On 1/1/21 5:07 PM, Selim Ozel wrote:
>> I created the simplest possible example as explained by the 
>> Vibe-D community in [1]. The exact source code of what I run 
>> is in [2].
>> 
>> On Windows I get a socket handle leak warning on shutdown with 
>> crtl+c from terminal after running the executable.
>> 
>>> [...]
>> 
>> On Ubuntu 20.04 I get leaking drivers warning with the same 
>> process.
>>> [...]
>> 
>> I really don't know what this is all about but it is at the 
>> core of my Vibe-D development. So any pointers you might have 
>> would be very helpful to me.
>> 
>> Thanks in advance.
>>
>
> 1. the sockets are leaked for a reason that is pretty obscure 
> -- namely, the GC might need to access those sockets as the 
> process is shut down. Prior to this, the end result of vibe.d 
> server was frequently a segfault.
> 2. The reason they are leaking is most likely because you still 
> have a listening socket somewhere. I wish it would tell you how 
> that socket was allocated, but it doesn't.
>
> To fix, make sure all your listening sockets are closed. In my 
> vibe.d app, I have the following:
>
> auto listener = listenHTTP(settings, router);
> scope(exit) listener.stopListening();
>
> I also clean up my session store connection (something I had to 
> add support for in vibe.d), which was a different source of 
> leaking handles.
>
> I also clean up database connections, which might be cached.
>
> And finally, even with all this, I still get leaking driver 
> messages if an HTTP keepalive socket is open.
>
> I really feel like vibe.d should give you the option of not 
> printing this message, as most of the time, it's something you 
> can ignore.
>
> -Steve

Hey Steve. Thanks a ton for all the tips. FWIW I am writing down 
my findings below because just maybe they might be helpful for 
someone else later on.

The scope guard seems to have fixed some of the leak complaints. 
Unfortunately there is still a leak after a single connection.

Without connection Windows 10:
> Running .\vibe_noleaks.exe
> [main(----) INF] Listening for requests on http://[::1]:8080/
> [main(----) INF] Listening for requests on 
> http://127.0.0.1:8080/
> [main(----) INF] Please open http://127.0.0.1:8080/ in your 
> browser.
> [00000000(----) INF] Received signal 2. Shutting down.
> [main(----) INF] Stopped to listen for HTTP requests on ::1:8080
> [main(----) INF] Stopped to listen for HTTP requests on 
> 127.0.0.1:8080

Without connection Ubuntu 20.04:
> Running ./vibe_noleaks
> [main(----) INF] Listening for requests on http://[::1]:8080/
> [main(----) INF] Listening for requests on 
> http://127.0.0.1:8080/
> [main(----) INF] Please open http://127.0.0.1:8080/ in your 
> browser.
> ^C[main(----) INF] Received signal 2. Shutting down.
> [main(----) INF] Stopped to listen for HTTP requests on ::1:8080
> [main(----) INF] Stopped to listen for HTTP requests on 
> 127.0.0.1:8080

After logging into to 127.0.0.1 for a single time in my browser, 
if I do a ctrl+c it still leaks two socket handles.

With connection Windows 10:
> Running .\vibe_noleaks.exe
> [main(----) INF] Listening for requests on http://[::1]:8080/
> [main(----) INF] Listening for requests on 
> http://127.0.0.1:8080/
> [main(----) INF] Please open http://127.0.0.1:8080/ in your 
> browser.
> [00000000(----) INF] Received signal 2. Shutting down.
> [main(----) INF] Stopped to listen for HTTP^ requests on 
> C::1:8080
> [main(----
> ) INFC:\Software\vibe_noLeaks>] Stopped to listen for HTTP 
> requests on 127.0.0.1:8080
> Warning: 2 socket handles leaked at driver shutdown.
> Warning: 2 socket handles leaked at driver shutdown.


I think vibe-d is also leaking more sockets when there is a web 
interface attached (not included in my toy repository). These 
haven't stopped me from developing but they are just things I 
wanted to write down and learn more before building even more 
infrastructure with it.

I might dive into vibe-d codebase at some point too.

Best,
S


More information about the Digitalmars-d-learn mailing list