ssl_context/3 leaks memory

[triska]

In packages/ssl, let alloc.pl consist of:

:- use_module(library(ssl)).

alloc :-
	ssl_context(server, _SSL,
		    [ certificate_file('etc/server/server-cert.pem'),
                      key_file('etc/server/server-key.pem'),
		      password(apenoot1)
		    ]),
        alloc.

Please run the test case:

$ swipl -g alloc alloc.pl

This allocates more and more SSL contexts that are not garbage collected. If possible, please make them collectible and free them when they are no longer needed. Thank you!

[JanWielemaker]

Pushed a couple of fixes. It is not all that clear which parts of the SSL object are automatically freed. It seems most of the stuff is reference count based and possibly we can share it. I now do that for the dh2048 structure, following code on the SSL site.

As the SSL structure is rather costly to create and mostly read-only, it would be a good idea to consider making it completely read only (I think it is notable the socket field that blocks this, but it might also be a good idea to get rid of the host field) and cache the context. That reduces the need for atom-gc as well.

[triska]

Please consider reopening this: The test case I posted still leaks memory, and there are several more remaining leaks. In fact, I think the whole freeing mechanism is not invoked in many cases.

[JanWielemaker]

It doesn't for me. Note that memory does grow for quite a while as the reclaim is called only per
10,000 contexts by AGC and some will remain due to the conservative nature of AGC. Eventually
the whole things seems to stabilise though and valgrind doesn't indicate issues. But, reclaiming the context is delicate. I think it would be a good idea to avoid creating that many.

[triska]

Please see the answer to life, the universe and everything in pull request #42, which fixes additional memory leaks I found. It's a relief that we are still slightly more intelligent than valgrind in finding such issues.

I think it would be a good idea to avoid creating that many.

Yes, dear Prolog programmers, please don't create so many HTTPS requests! In all seriousness though, I must make library(ssl) run 100% free of leaks, because contexts are created not only for the server, but for each HTTPS link a client opens, and there is no bound on this number.

[JanWielemaker]

Thanks for those. My plea for not creating that many is not to write different programs, but to change the context to be fully read-only (now it is 99% read only) and share them. That saves time and memory, and quite a bit.

[triska]

Yes, that would be great! I am currently working on server-side SNI, and in that specific case, the server-side contexts cannot be shared, but I see that it would be useful in other applications.

The socket field seems to be used only with the deprecated API of library(ssl). If that can be abandoned, I think the contexts could be shared.