Since the 0.4 update, we sometime (rarely, but happens from time to time) this panic:
panicked at 'called `Option::unwrap()` on a `None` value', /home/vthib/.cargo/registry/src/github.com-1ecc6299db9ec8
23/windows-dll-0.4.0/src/cache.rs:76:45
Reading the code, I can see a race condition which can make this happen. From what I can tell from the code:
DllCache::get gets the dll handle, and if not loaded yet, loads it (DllCache::load_and_cache_lib)
DllCache::load_and_cache_lib loads the dll handle, stores it, then initializes the procs once_cell
DllCache::get_proc_ptr calls DllCache::get, then uses procs, which should have been initialized
This is racy:
Thread 1 calls get_proc_ptr, which enters get then load_and_cache_lib, and stores the handle
Thread 2 calls get_proc_ptr, which enters get, which returns the loaded handle stored by thread 1. Thread 2 proceeds with accessing procs, which is not yet initialized by thread 1
One solution should be to only store the handle after the initialization of the procs once_cell in load_and_cache_lib.
Since the 0.4 update, we sometime (rarely, but happens from time to time) this panic:
Reading the code, I can see a race condition which can make this happen. From what I can tell from the code:
DllCache::getgets the dll handle, and if not loaded yet, loads it (DllCache::load_and_cache_lib)DllCache::load_and_cache_libloads the dll handle, stores it, then initializes theprocsonce_cellDllCache::get_proc_ptrcallsDllCache::get, then usesprocs, which should have been initializedThis is racy:
get_proc_ptr, which entersgetthenload_and_cache_lib, and stores the handleget_proc_ptr, which entersget, which returns the loaded handle stored by thread 1. Thread 2 proceeds with accessingprocs, which is not yet initialized by thread 1One solution should be to only store the handle after the initialization of the procs once_cell in
load_and_cache_lib.