The chances of this being a bug in OpenSSL is effectively zero. With just about complete certainty, this a bug in your code. Just because it always seems to crash in the same OpenSSL function doesn't mean it's an OpenSSL bug. Your code is quite likely passing bad data to that function - the function the crash happens in is the victim, not the culprit. It could be a race condition given you're using multiple threads, it could be your process running out of memory because of a memory leak, resulting in your code passing a NULL pointer to the victim function because the allocation call failed. Or your code is mishandling data somehow - perhaps by accessing data via a free()'d pointer or overwriting a buffer somewhere. Both of those could easily result in intermittent failures that take a long time to manifest.

It's not evidence of a bug in OpenSSL until you can provide a minimal example that does nothing but call that function in a way that exactly replicates the problem, and you can literally prove that there is no bug in your simple example - likely because the code that demonstrates the bug is so simple anyone looking at it can see it's bug-free. The history of OpenSSL is long, and it's used just about everywhere, and it's used without failing like it does in your application.

So how do you find where the bug is?

First, make sure you're using the OpenSSL functions properly, as @star noted in the other answer. Because when used per its documentation, OpenSSL is thread-safe. Period. Full stop. Again - OpenSSL is used almost everywhere and it has a long history of fundamental stability. If you think the problem is in OpenSSL, the burden is on you to prove it. Literally. You quite literally have to overcome, "Well, OpenSSL works just fine for pretty much the entire planet, but not for you? But you're claiming it's an OpenSSL bug? Ok, so PROVE it."

Second, at what warning level are you compiling your code? Raise the warning level on your compiler as high as it goes, and fix EVERY warning. Yes - EVERY SINGLE ONE. A warning from a compiler happens when the writers of the compiler you're using to turn your code into a runnable executable decide to do extra work to tell you,

We think your code here is so dodgy we're going beyond what the language standard says we need to do and we're spending a lot of extra effort to tell you that you probably need to fix this even though it doesn't violate the language syntax.

Why would anyone even try to argue against fixing warnings? The language experts who wrote the compiler you're using to translate your code into something runnable went out of their way to tell you they think your code is dodgy. And that means your code is dodgy - at best. Code with lots of warnings doesn't have a smell, it's two-weeks-dead-skunk-in-a-fetid-sewer, peels-the-stripes-off-the-road, flesh-melting rank.

Third, use Valgrind or a similar memory-checking tool on your program. Your code should be clean, with zero errors. If you run under Valgrind and get a lot of errors in your code and find yourself thinking, "Valgrind is garbage, there's no way my code is this bad", have your head removed, taken to a repair shop, x-rayed, CT-scanned, MRI'd, have its defects fixed and dents hammered out, and then have your head bolted back on your shoulders straight. That may sound harsh, but I've heard developers actually saying things like that publicly - and I never thought of them as competent again. Because yes, your code can most definitely be that bad - anyone's can. It's not hard to mess up some pointer arithmetic so that every last bit of code depending on that pointer's value is dangerously bad. So if Valgrind complains about your code, fix your code. It's broken.