Closed micl2e2 closed 1 year ago
You correctly close the instance. The data leaks inside SQLCipher
code, so you can try to find the cause and report the issue to them, if it isn't fixed yet.
Anyway, given that < 100 bytes leaks per created and closed instance, it will take centuries to make the leak noticeable in a real app.
Thanks for the clarification!
Xin code trải nghiệm
Vào 23:20, Th 2, 18 thg 9, 2023 Michael Lee @.***> đã viết:
Closed #2608 https://github.com/tdlib/td/issues/2608 as completed.
— Reply to this email directly, view it on GitHub https://github.com/tdlib/td/issues/2608#event-10400235657, or unsubscribe https://github.com/notifications/unsubscribe-auth/A5AUF4W2E2HQBCXU7YNUIUTX3BYDFANCNFSM6AAAAAA44P2L7U . You are receiving this because you are subscribed to this thread.Message ID: @.***>
After running valgrind's memcheck against the original example
example/cpp/td_example
, it detects memory leak, the reproduciable steps are:, where we
close
before[q] quit
, which might be the correct way to end the TDLib instance, but it seems not. There are still 62 bytes "Definitely lost" in one of my tests(the most common one, sometimes 80+ bytes, few times 90+ bytes). As per valgrind docs, this should be fixed otherwise causing memory leak.Even with
close
action, the original example seems not strictly following the official guidelines, which suggests that the eventauthorizationStateClosed
shall be the actual signal of TDLib instance closing.Additionally, even though following the guideline, meaning our program exits only after
authorizationStateClosed
event received (my modified and simplified version oftd_example.cpp
implements it), that 62 bytes lost still exists. And the those lost positions are identical in both original one and my modified one, two 31-byte blocks, one starting fromtd::create_story_db_sync
, the other starting fromtd::detail::LambdaPromise::set_value
, the details are: