Bug #15852


Added by (Alexander Riccio) almost 2 years ago. Updated 9 days ago.

Target version:
ruby -v:
ruby 2.6.3p62 (2019-04-16 revision 67580) [x64-mingw32]


Ruby appears to be freeing some critical section in ruby_vm_destruct before deleting the critical section. Critical Section objects must be deleted with DeleteCriticalSection ( before freeing the owning memory.

I can't tell exactly what critical section is being freed - I'm new to ruby, don't know how the VM works, and haven't built it locally - so I can't help you guys there yet.

The clean stack trace is:

0:000> kc
 # Call Site
00 vrfcore!VerifierStopMessageEx
01 vfbasics!AVrfpFreeMemLockChecks
02 vfbasics!AVrfpFreeMemNotify
03 vfbasics!AVrfpRtlFreeHeap
04 msvcrt!free
05 vfbasics!AVrfp_free
06 x64_msvcrt_ruby260!ruby_xfree
07 x64_msvcrt_ruby260!ruby_vm_destruct
08 x64_msvcrt_ruby260!ruby_cleanup
09 x64_msvcrt_ruby260!ruby_run_node
0a image00000000_00400000
0b image00000000_00400000
0c image00000000_00400000
0d KERNEL32!BaseThreadInitThunk
0e ntdll!RtlUserThreadStart

I'm running C:\Ruby26-x64\bin\ruby.exe -x "C:\Ruby26-x64\bin\irb.cmd", with Application Verifier lock verification enabled. Application Verifier is the Windows SDK dynamic analysis tool, and it can be enabled by anybody who's installed the SDK. Add ruby.exe to the list of applications in Application Verifier and then run irb from inside windbg. Leak analysis should be enabled by default.

I've attached the full debug log in Windbg.


ruby_freeing_active_critsec.TXT (17.2 KB) ruby_freeing_active_critsec.TXT (Alexander Riccio), 05/15/2019 09:00 PM

Updated by (Alexander Riccio) almost 2 years ago

Uhh, I don't know how to add maintainers, sorry!

Updated by (Alexander Riccio) 19 days ago

Still active as of Ruby 3.0.0p0 (x64-mingw32). I've done some more digging, and it appears to be freeing the Thread_Mutex in rb_call_inits (inits.c), aka the Init_Thread_Mutex function in thread.c.

Updated by (Alexander Riccio) 19 days ago

How do I assign? It looks like this should go to ko1 (Koichi Sasada) (eval) or nobu (Nobuyoshi Nakada) (mingw)


Updated by nobu (Nobuyoshi Nakada) 9 days ago

vm->waitpid_lock and vm->workqueue_lock seem never deleted.
rb_native_mutex_destroy on them are disabled by if (0) in rb_vm_gvl_destroy(), and that function is not called from anywhere too.
I have no idea why these calls are disabled.

Also available in: Atom PDF