Skip to content
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

"Cannot change thread mode after it is set." error when calling cpu.Info() #692

Open
1 of 5 tasks
boeckstefan opened this issue May 24, 2019 · 1 comment
Open
1 of 5 tasks

Comments

@boeckstefan
Copy link

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]
@Lomanic
Copy link
Collaborator

Lomanic commented May 28, 2019

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.

Implementation in datadog/gohai https://github.com/DataDog/gohai/blob/107ebc5d16adf023a132bd93174fec57d482c3c2/cpu/cpu_windows.go

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants