You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Windows only!
cpu.Info() is called every 5 minutes. Sometimes it returns said error. While reproducing is difficult, further investigation (see, issue #618) suggest that it could be some kind of a race condition. Other calls against net.Interface or net.IOCounters are made, without them the error will not occur. The project were this problem occurs also uses cpu, mem, host, process and disk routines.
My investigations so far:
gopsutils uses StackExchange/wmi tools. These tools use a mutex to block concurrent calls against wmi. But those mutex are part of the wmi object, by creating a wmi object for every call (e.g. process.Info(), disk.IOCounters()) those mutex are useless.
Well manually syncing these calls didn't help
cpu.Info() and net.IOCounters don't use wmi but use golang.org/x/sys/windows. Reading through the windows modul we see that some calls against windows .dll are made. Question is need they to be locked? Are they interfering with wmi calls internally?
Solution could be a modul lock for any windows calls (timeouts, performance, new behaviour)
If my suspicion is correct, i suggest documenting it at least for affected methods.
To Reproduce
// reproducing is difficult due to the nature of this problem
Expected behavior
No error, valid data.
Environment (please complete the following information):
Windows: Microsoft Windows [Version 6.1.7601]
Linux: [paste contents of /etc/os-release and the result of uname -a]
Mac OS: [paste the result of sw_vers and uname -a
FreeBSD: [paste the result of freebsd-version -k -r -u and uname -a]
OpenBSD: [paste the result of uname -a]
The text was updated successfully, but these errors were encountered:
Thanks for your investigation and your report, but WMI is indeed used in cpu.Info and disk.IOCounters.
Solution should be to remove calls to WMI (as always…) as they are slow and unreliable. For getting CPU info, I remember there are some registry entries available, but information is insufficient compared to what is returned by this WMI request AFAIR.
Describe the bug
Windows only!
cpu.Info() is called every 5 minutes. Sometimes it returns said error. While reproducing is difficult, further investigation (see, issue #618) suggest that it could be some kind of a race condition. Other calls against net.Interface or net.IOCounters are made, without them the error will not occur. The project were this problem occurs also uses cpu, mem, host, process and disk routines.
My investigations so far:
process.Info()
,disk.IOCounters()
) those mutex are useless.golang.org/x/sys/windows
. Reading through the windows modul we see that some calls against windows.dll
are made. Question is need they to be locked? Are they interfering with wmi calls internally?To Reproduce
// reproducing is difficult due to the nature of this problem
Expected behavior
No error, valid data.
Environment (please complete the following information):
/etc/os-release
and the result ofuname -a
]sw_vers
anduname -a
freebsd-version -k -r -u
anduname -a
]uname -a
]The text was updated successfully, but these errors were encountered: