GC strategies should be double-checked.

[lunixbochs]

Any time a C struct is allocated under a Go struct, a GC finalizer should be added to the Go struct with runtime.SetFinalizer, unless "ownership" of the object passes to OpenSSL (which is hard to verify).

For this to work, Go objects need to maintain references to potentially GC-able objects, otherwise OpenSSL allocations still in use when GC runs will cause segfaults as in #10.

This can be made simpler for some objects with a 1:1 mapping by embedding C structs in Go objects and using OpenSSL's _init() instead of _new() functions, like done by the SHA implementation.

Examples:

• EVP_PKEY_free is called, but maybe needs to be tracked on Ctx when you call a UsePrivateKey() function or set a key on a cert (in theory)
• When you add a certificate to a context or certificate store, the certificate must be both added to the C structure and the Go object.

[lunixbochs]

How do functions like CertificateStore.GetCurrentCert interact with OpenSSL's memory management? Does it really allocate a new X509 structure that needs to be freed? If we dump a cert into a store and pull it back out, is it a pointer to the same address?

[jtolio]

further complicating things is that when you get a reference to an underlying C structure from openssl, sometimes it is a new object you have to free, and sometimes it is an object who has a lifetime bound to the parent object and no free of the child object is necessary or needed

[lunixbochs]

Yeah, that's why I have TODO on Name GC stuff.

[jtolio]

oh, okay got it