mirror of https://github.com/sipwise/kamailio.git
With newer OpenSSL versions it seems a threaded application needs to cleanup properly, otherwise the now automatic atexit() cleanup handler will segfault when the pthread variables have been deallocated already by the pthreads library. Change-Id: I08ac91cf63b1a74c17a0bd70b40202a5baf7771fchanges/87/14687/2
parent
2c01279113
commit
a7391e56fd
@ -0,0 +1,38 @@
|
||||
Description: Explicitly call OPENSSL_cleanup() on TLS module destruction
|
||||
Kamailio is a threaded program, and it pulls OpenSSL via a dynamically
|
||||
linked plugin loaded at run-time via dlopen().
|
||||
.
|
||||
Older OpenSSL releases do not perform automatic cleanup on exit, newer ones
|
||||
do via an atexit() handler.
|
||||
.
|
||||
In addition the OpenSSL code leaks (on purpose) a DSO handler for itself so
|
||||
that it can guarantee that the library is still present when the atexit()
|
||||
handler is executed.
|
||||
.
|
||||
When the handler is called, a pthread variable is still present but the
|
||||
memory it points to is not allocated anymore, which indicates something else
|
||||
released those pthread memory pools. Most probably pthreads itself as part
|
||||
of its deconstructors, pthread_exit() or atexit() handlers while unwinding
|
||||
or being unloaded.
|
||||
.
|
||||
Explicitly calling the OpenSSL cleanup code fixes the issue for newer
|
||||
OpenSSL releases, where this has been made visible. And the documentation
|
||||
for OPENSSL_cleanup() mentions that explicit cleanup might be needed in
|
||||
these conditions anyway.
|
||||
Origin: other, Sipwise
|
||||
Author: Guillem Jover <gjover@sipwise.com>
|
||||
Bug-Debian: https://bugs.debian.org/870018
|
||||
|
||||
---
|
||||
|
||||
--- a/modules/tls/tls_init.c
|
||||
+++ b/modules/tls/tls_init.c
|
||||
@@ -778,4 +778,8 @@ void destroy_tls_h(void)
|
||||
tls_destroy_cfg();
|
||||
tls_destroy_locks();
|
||||
tls_ct_wq_destroy();
|
||||
+
|
||||
+#if OPENSSL_VERSION_NUMBER >= 0x010100000L
|
||||
+ OPENSSL_cleanup();
|
||||
+#endif
|
||||
}
|
||||
Loading…
Reference in new issue