Add more checks on host_processor_info

[GuillaumeGomez]

Fixes #1205.

Hopefully this fixes the bug... Can you check if it fixes your issue @SpyMachine?

[SpyMachine]

This branch doesn't build. I get the same errors as GH is annotating:

    Updating git repository `https://github.com/GuillaumeGomez/sysinfo.git`
   Compiling sysinfo v0.30.5 (https://github.com/GuillaumeGomez/sysinfo.git?branch=host-processor-call#cb5121c4)
error[E0425]: cannot find value `cpu_count` in this scope
   --> /Users/gkuruc/.cargo/git/checkouts/sysinfo-bc2293244598544b/cb5121c/src/unix/apple/cpu.rs:266:16
    |
266 |             && cpu_count > 0
    |                ^^^^^^^^^ not found in this scope

error[E0425]: cannot find value `cpu_load` in this scope
   --> /Users/gkuruc/.cargo/git/checkouts/sysinfo-bc2293244598544b/cb5121c/src/unix/apple/cpu.rs:267:17
    |
267 |             && !cpu_load.is_null()
    |                 ^^^^^^^^ not found in this scope

For more information about this error, try `rustc --explain E0425`.
error: could not compile `sysinfo` (lib) due to 2 previous errors

[GuillaumeGomez]

I badly failed my rebase. ^^' Should work better now.

[SpyMachine]

Same issue unfortunately :(

Thread 6 Crashed:: diagnostic_context.rb:471
0   libsystem_kernel.dylib        	       0x1835f9874 mach_msg2_trap + 8
1   libsystem_kernel.dylib        	       0x18360bcf0 mach_msg2_internal + 80
2   libsystem_kernel.dylib        	       0x18361a84c host_processor_info + 148
3   libsysinfo_gem.dylib          	       0x109c46068 0x109bd4000 + 467048
4   libsysinfo_gem.dylib          	       0x109bd9500 0x109bd4000 + 21760
5   libruby.3.1.dylib             	       0x105956628 vm_call_cfunc_with_frame + 232 (vm_insnhelper.c:3037)
6   libruby.3.1.dylib             	       0x105958d4c vm_sendish + 1336
7   libruby.3.1.dylib             	       0x10593b680 vm_exec_core + 8128 (insns.def:778)
8   libruby.3.1.dylib             	       0x10594de70 rb_vm_exec + 2212

Is there any logging I can get that would be helpful?.

[GuillaumeGomez]

I'm sorry, I have absolutely no idea... It seems that it's failing inside host_processor_info. At this point I suspect that I'm doing something wrong somewhere else that could have this crash as side-effect. The best course from here would be to write a code that triggers it all the time so then we can check more precisely what's going on (with a memory checker for example?).

[SpyMachine]

Hmm okay I'll keep trying but yeah I haven't been able to compile a simple reproducible case yet. It doesn't even happen all the time in the program we are working on. I think I read somewhere that the guard might have something to do with file descriptors and we do make a lot of network requests via libcurl so it may be something with that.

[SpyMachine]

Hi @GuillaumeGomez. I was able to come up with something that reproduces about 50% of the time for me and is relatively small. There are instructions in the zip on how to compile and run. It requires using Ruby because it appears that instantiating a specific class from the Typhoeus gem is required to reproduce.

Sorry if it's a pain I tried to pair it down as much as possible.

So I've discovered there's two requirements to make this happen:

1. Forking off another process and in that other process,
2. Initializing an instance of Typhoeus::Hydra in ruby and requesting the cpu_usage

Hope this helps. Let me know if there's anything else I can do. Thanks!

reproduce.zip

[GuillaumeGomez]

Nice thanks! I don't have a mac M1 so I can't check locally unfortunately. Maybe a call for help on social media could help? ^^'

[SpyMachine]

Oh I meant to put this here...

#1205 (comment)