-
-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: Memory leaks reported by mumble #81
Comments
I once again advise you to rework your plugin so it uses https://github.com/mumble-voip/mumble-plugin-cpp as a base. When using the cpp based API, memory management is automated and you never have to worry about it. |
Hi @Krzmbrzl thank you for the hint, i opened a ticket for that (#82) so it won't get overlooked. However, i really want to learn and understand what causes this, because i want to better understand the pitfalls of C/C++ programming in order to get better :) |
A valgrind run: valgrind.txt Lets me behind clueless. |
Another, more verbose file gives hints: valgrind-3.txt.gz Plugin built with:
|
@Krzmbrzl i get pointed to my call of the sync status, but i don't know whats wrong with that:
code is: bool fgcom_isConnectedToServer() {
//pluginDbg("fgcom_isConnectedToServer(): checking connection");
bool synchronized;
int resCode = mumAPI.isConnectionSynchronized(ownPluginID, activeConnection, &synchronized);
if (STATUS_OK != resCode) {
return false;
}
return synchronized;
} Should'nt the bool get freed automatically after the context to where it returned to is finished, because it's a stack variable? |
You won't find this leak by using valgrind. This is not a leak caused by you calling Instead these leaks are created if you e.g. ask for a user's name via API. The String for that name will be allocated on Mumble's side (via The message you are seeing indicates that you did not call the free API function for a couple of such resources (Strings or arrays obtained via API) and thus the automatic fail-safe on Mumble's side kicks in (freeing the memory after all but only when Mumble is shutting down). |
So in this case for example, the bool is not freed after i returned it? |
No. Boolean values do not need freeing. |
Hm, however i looked trough all my invocations of mumAPI and couldn't find things not freed that are indicated from the header file comments... Just an idea: You probably store the pointers in mumble somewhere, so you can later hook up the cleaning routine. |
@Krzmbrzl I could isolate a code part where it seems to trigger a leak: mumble_userid_t localUser;
if (mumAPI.getLocalUserID(ownPluginID, activeConnection, &localUser) != STATUS_OK) {
pluginLog("Failed to retrieve local user ID");
return EC_USER_NOT_FOUND; // abort online init - something horribly went wrong.
} else {
// update mumble session id to all known identities
localMumId = localUser;
fgcom_remotecfg_mtx.lock();
for (const auto &idty : fgcom_local_client) {
fgcom_local_client[idty.first].mumid = localUser;
}
fgcom_remotecfg_mtx.unlock();
pluginLog("got local clientID="+std::to_string(localUser));
mumAPI.freeMemory(ownPluginID, &localUser);
} |
That should be possible, yes. |
What are you doing there? This doesn't seem to make any sense. Why are you trying to free the user ID? 👀 As can be seen in the docs of that function you don't have to free the user's ID. |
😇 |
Describe the bug
While debugging #78 we again got some messages reporting memory leaks:
This does not happen always.
This needs further research, where the memory is not freed.
The text was updated successfully, but these errors were encountered: