-
-
Notifications
You must be signed in to change notification settings - Fork 74
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
memory leak #76
Comments
Hi @Six0Ne, thank you for reporting your concerns. I will evaluate your points. Concerning your second point: |
Hello, I mean no harm; Regarding the second point, the theory is the same as what you said, we pass a memory address as a parameter, and the function will use that address and overwrite the existing data. We only need to release the address once; but in fact, doing so will indeed cause the memory to increase abnormally. As a simple test, put auto cpus = hwinfo::getAllCPUs(); into while(1) and run, we will find The memory of the program will grow abnormally; |
Well, doesn't look that nice indeed 😅 Feel free to submit a pull request. Else, I will try to approach the issue in the next few days. Thanks for the report! |
Okay, please update it. |
Hello, in your code, I found two places that easily lead to memory leaks; 1. I noticed that the memory space and resources of wmi.enumerator were not released before each query was run. This can result in a new WMI enumerator object being created each time the query is run, without the old object being freed, resulting in a memory leak. 2. When calling the hr = obj->Get(L" ", 0, &vt_prop, nullptr, nullptr) function multiple times, a new vt_prop object will be created each time it is run. You only use VariantClear(&vt_prop) the last time ;In fact, this will only release one of the vt_prop objects. The correct approach should be to call obj->Get() every time, followed by VariantClear().
![截图2](https://private-user-images.githubusercontent.com/79785896/298482006-bf4a3eac-291b-4bca-8a6a-4bb5598c7a58.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjQwNDYxNjQsIm5iZiI6MTcyNDA0NTg2NCwicGF0aCI6Ii83OTc4NTg5Ni8yOTg0ODIwMDYtYmY0YTNlYWMtMjkxYi00YmNhLThhNmEtNGJiNTU5OGM3YTU4LnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNDA4MTklMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjQwODE5VDA1Mzc0NFomWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPTdjMDk1ZDBjNWI5ZDU1MTg4NWE0NWY2MDdjZDFiZTg0OWJjZWMyNWY1MjIzOTg3YzVjYjU2NGJkMTc1YWFiNzEmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JmFjdG9yX2lkPTAma2V5X2lkPTAmcmVwb19pZD0wIn0.QIhgpJH_5lFAZD_jqS5T_LUoV-uAlFLizRzcF8cfN7c)
The text was updated successfully, but these errors were encountered: