Details
-
Bug
-
Resolution: Out of scope
-
P3: Somewhat important
-
None
-
5.5.1
-
None
-
Ubuntu Linux 14.04 x64
Windows 7 x64
Description
I have written a client library that communicates with my server through a QSsl connection.
The library is working fully-syncronous (i.e. uses the waitForEncrypted() and related functions) by writing commands to the server and read back the answer.
Now a customer told me, that there is a memory leak within my library, and with valgrind I found this is related to QSslSocket / QSslCertificate.
Attached is a simple Server/Client project that illustrates the issue. The file QSslLeak/SslClient/valgrind_log.txt was created by running:
valgrind --leak-check=full --show-leak-kinds=all ./SslClient
Part of the valgrind output that repeats several times:
==11027== 8 bytes in 1 blocks are still reachable in loss record 6 of 612
==11027== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11027== by 0xA128DB2: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==11027== by 0xA1A5D62: BUF_strndup (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==11027== by 0xA1FB5A6: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==11027== by 0xA1FBC63: CONF_module_add (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==11027== by 0xA1FBFED: OPENSSL_load_builtin_modules (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==11027== by 0xA1FC018: OPENSSL_config (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==11027== by 0x4F2FA29: ??? (in /opt/Qt/5.5/gcc_64/lib/libQt5Network.so.5.5.1)
==11027== by 0x4F320C8: ??? (in /opt/Qt/5.5/gcc_64/lib/libQt5Network.so.5.5.1)
==11027== by 0x4F14E66: QSslCertificate::QSslCertificate(QByteArray const&, QSsl::EncodingFormat) (in /opt/Qt/5.5/gcc_64/lib/libQt5Network.so.5.5.1)
==11027== by 0x4F2321C: ??? (in /opt/Qt/5.5/gcc_64/lib/libQt5Network.so.5.5.1)
==11027== by 0x4F320F8: ??? (in /opt/Qt/5.5/gcc_64/lib/libQt5Network.so.5.5.1)
Edit (from T.P.): minor (possible) leaks in OpenSSL reported by Valgrind are not an issue, the real problem is "backend-neutral" - it is Qt::QueuedConnection and invokeMethod we call in different places in QSslSocket. Without a normal event loop this will result in ever-growing event queue that never gets processed/emptied.