Details
-
Bug
-
Resolution: Done
-
P1: Critical
-
4.5.3
-
None
-
-
d4d7f3575c229848f08c7df75a1281755d6c41a8, 02f2ac6d090547f5b13534d77fe7761d6f236fb2
Description
This leak is apparent when using a subclass of the QSslSocket.
The attached example demonstrates the memory leak, but only with SSL enabled. Non-SSL will use the same class but with no memory leak.
in order to observe this leak, the server and client in the attached example need to be
run in separate processes. I just performed a test as follows:
process 1: >./SSL_Leak_Test 1 1 // this will start a server process
using SSL
process 2: > ./SSL_Leak_Test 2 1 // this will start a client process
using SSL
where process 2 (the client with the leak) climbs slowly to 9.36MB
of memory, which is never reclaimed; even after the socket is
destructed. This is exactly the problem we're having at Filewave.
I suggest making it more obvious and observable by increasing the
following parameter in Globals.cpp:
quint32 LeakGlobals::CLIENT_WRITE_ITERATIONS // from = 50,000 to
500,000.
This takes a little while, but you should observe about 52MB of
memory which is never reclaimed.
Attachments
Issue Links
- depends on
-
QTBUG-6504 Potential memory leak in QSslSocket
- Closed
- relates to
-
QTBUG-12476 SSL Memory leaks (with screenshots + valgrind report).
- Closed