Closed JRAndreassen closed 1 year ago
Hi @JRAndreassen!
I'm not sure I understand your setup 🤔
Are you running cargo test
in wmi-rs
? Do your app's tests get stuck and never finish?
Note that cargo test
uses multithreading by default to run tests in parallel, which might also explain what you are seeing.
For me running locally I see the expected number of threads (1 for the app, 1 from COM) for:
A simple app which creates a connection and waits:
use std::io::{self, Read};
use wmi::{COMLibrary, WMIConnection};
fn main() {
let com_con = COMLibrary::new().unwrap();
let wmi_con = WMIConnection::new(com_con.into()).unwrap();
let p_svc = wmi_con.svc();
assert_eq!(p_svc.is_null(), false);
let mut buffer = String::new();
io::stdin().read_line(&mut buffer).unwrap();
}
And a simple test (with this code after the code from above):
#[cfg(test)]
mod tests {
use super::*;
#[test]
fn it_works() {
let com_con = COMLibrary::new().unwrap();
let wmi_con = WMIConnection::new(com_con.into()).unwrap();
let p_svc = wmi_con.svc();
assert_eq!(p_svc.is_null(), false);
let mut buffer = String::new();
io::stdin().read_line(&mut buffer).unwrap();
}
}
@ohadravid : Thanks for getting back to me...
The app runs just fine, it is a resource consumption issue... When I run the test (or my app), the the call to "WMIConnection::new(com_con.into())" leaves behind 40+ threads (who appear "dead" or may be threads blocked on a wait condition waiting unload the Dll)... Given the stack:
NtWaitForAlertByThreadId (@NtWaitForAlertByThreadId:8) RtlSleepConditionVariableSRW (@RtlSleepConditionVariableSRW:80) SleepConditionVariableSRW (@SleepConditionVariableSRW:14) DllCanUnloadNow (@DllCanUnloadNow:10814)
I have not seen that in any other Windows rust crates, like "winreg" ... I'm just trying to find out what's causing them and if there is a way to get around it... 40+ "dead" threads is a bit excessive... JR
Could you try to create a minimal reproduction (a complete crate / a demo repo I could compile)? As I said, in my env with the code above I only see a single thread.
Also can you please provide the method used to list the threads?
@ohadravid ,
I happens with the test above... Both in VSCode debugger and release code. I'm using the LLDB Debugger and the task list... I'll try to make a example... JR
@ohadravid ...
One thing that might help is if you send me your "Cargo.lock"... Then we can see if there is a library difference...
Closing for now, feel free to reopen if you can create a repro 🙏
Hi...
I had something strange happen... the Connection.rs test (and my app) leaves behind 40+ threads after the call to Connection new:
It happens in ConnectServer:
NtWaitForAlertByThreadId (@NtWaitForAlertByThreadId:8) RtlSleepConditionVariableSRW (@RtlSleepConditionVariableSRW:80) SleepConditionVariableSRW (@SleepConditionVariableSRW:14) DllCanUnloadNow (@DllCanUnloadNow:10814) DllCanUnloadNow (@DllCanUnloadNow:10814) DllCanUnloadNow (@DllCanUnloadNow:10814) DllCanUnloadNow (@DllCanUnloadNow:5416) DllCanUnloadNow (@DllCanUnloadNow:10814) DllCanUnloadNow (@DllCanUnloadNow:5044) DllCanUnloadNow (@DllCanUnloadNow:10814) BaseThreadInitThunk (@BaseThreadInitThunk:9) RtlUserThreadStart (@RtlUserThreadStart:12)
Any ideas ?
Thanks JR