> Perhaps you're freeing some objects that are owned by the library, or > continuting to use objects that the library owned and freed. I don't think so, I'm using the reference counter whenever I can (for instance with the trust store). Also, SSL_CTX is never destroyed. > What you're doing should work, if implemented correctly, but my advice > is to not use SSL_clear(), rather create a fresh (SSL *) handle for > each connection. These are cheap enough to not warrant recycling. Using a fresh (SSL *) seems to work. So I guess there is something wrong with SSL_clear() ? > On 27 Sep 2022, at 18:42, Viktor Dukhovni <openssl-users@xxxxxxxxxxxx> wrote: > > On Tue, Sep 27, 2022 at 06:35:47PM +0200, Thomas Bailleux wrote: > >> However, I am still facing issues when I use `SSL_CTX` and `SSL` objects. >> >> I use `SSL_CTX` and `SSL` inside a threaded application. Threads are managed using pthread primitives. >> >> Basically, I create a `SSL_CTX`, and I fill it depending on the TLS method. >> At this point, the `SSL_CTX` is final. I never change it again. >> >> Then, I create n `SSL`s from the `SSL_CTX`, and I spawn n pthreads. >> Each pthread takes the ownership of a single `SSL`. Finally, each >> pthread is going to use its `SSL` object for establishing some TLS >> connections. `SSL` objects never get destroyed, instead I use >> `SSL_clear` for kind of recycling them. > > Perhaps you're freeing some objects that are owned by the library, or > continuting to use objects that the library owned and freed. > >> My question is: Is my app thread safe ? I wonder, because I am facing >> random null deref. If I create a `SSL_CTX` for each thread, >> everything is fine. > > What you're doing should work, if implemented correctly, but my advice > is to not use SSL_clear(), rather create a fresh (SSL *) handle for > each connection. These are cheap enough to not warrant recycling. > > -- > Viktor.
