Closed kastger closed 4 months ago
@kastger Thank you for taking your time writing the issue and providing such a good PoC.
I link a chapter from the docs where i wrote something about the memory issues: https://bogdanfinn.gitbook.io/open-source-oasis/shared-library/memory-issues
The important part:
By design there is memory allocated for every response coming from the go implementation (shared library) to the invoking application (python, node, etc.). The caller has to free the memory when he is done with handling the response. otherwise the memory will never be freed and you run into memory issues.
So you are already doing good destroying the sessions (which is btw not needed if you reuse sessions). But you forgot to free the actual memory which needs to be allocated for communication between the shared library and the invoking application.
There is the special freeMemory()
function you basically need to call after every interaction with the shared library in order to free this memory.
Thank you for such quick answer.
I have tested by changing destroyAll()
to freeMemory(response_object["id"].encode("utf-8"))
in my previous example and it seems to have worked.
TLS client version
v1.7.5
System information
NAME="Linux Mint" VERSION="21.2 (Victoria)" ID=linuxmint ID_LIKE="ubuntu debian" PRETTY_NAME="Linux Mint 21.2" VERSION_ID="21.2" VERSION_CODENAME=victoria UBUNTU_CODENAME=jammy
Issue description
The issue was noticed in
tls-client
wrapper, but it is also present when using compiled lib. The code is taken fromexample_python
add executed in a loop. For this issue I did 50 requests to the same url and tracked memory usage:I have tested memory on pure Go and everything seemed to be fine. Is there an issue in the example or is something wrong with how memory is managed in Python in this case?
Steps to reproduce / Code Sample