Memory leak?

[carlpett]

Hi!
We're using this library in the Prometheus wmi_exporter, thanks alot for open sourcing it! We are investigating a memory leak, and after quite a bit of digging around, it seems like it comes from this library.
I've read #3 and the associated work, but it seems to me those should have been fixed long ago?

The memory that is leaked seems to be native, Go's pprof does not recognize that the memory is allocated any more. How can I help figure this out? I've been trying to learn windbg and debugdiag for a few hours now, without really having much to show for it.

The leak is on the order of around a hundred megabytes per week when doing 50 calls to CreateQuery/Query per minute, if that gives any indication of what could be going wrong.

[carlpett]

Here is some typical code, and here is our corresponding issue for context.

[gbrayut]

If you are using Windows 10 or Server 2016 (or possibly WMF 5.x on older versions) you are likely hitting a WMI private working set memory leak we found when calling ole.CoInitializeEx from multiple goroutines (see go-ole/go-ole#135 for context). We were able to fix the leak in scollector by refactoring the wmi package to use a single background goroutine when interacting with WMI.

The current master branch on StackExchange/wmi already has the fix (merged in #23 ), but you need to initialize the wmi package prior to executing any WMI queries to opt into the new behaviour (you need lines 19-23 from https://github.com/bosun-monitor/bosun/pull/2028/files#diff-60022ac613446237a5e9e6a1cbef3a8dR19 ).

[carlpett]

Aha, thanks! I will try that.

[carlpett]

This resolved our issue, thank you very much!
🍰