Having a hard time coming up with a clean patch here. The following works but it's pretty hacky. ~~~ diff diff --git a/load.c b/load.c index fa225fa..68d15e7 100644 --- a/load.c +++ b/load.c @@ -952,6 +952,9 @@ rb_require_safe(VA...tmm1 (Aman Karmani)
This gets much worse as $LOAD_PATH grows. For example in our app $LOAD_PATH.size is 351, causing 702 failed open() syscalls per require.tmm1 (Aman Karmani)
On every invocation of `require "enumerator"` (for example during boot when many gems require it), the VM will scan the load path twice: once for enumerator.rb and again for enumerator.so. Of course, no file is found because enumerator i...tmm1 (Aman Karmani)
Applied in changeset r49474. ---------- gc.c: ensure GC state is consistent during VM shutdown * gc.c (rb_objspace_free): cause rb_bug if lazy sweep is in progress during rb_objspace_free. Adds extra protection for r46340. Patch by...tmm1 (Aman Karmani)
* gc.c (rb_objspace_free): cause rb_bug if lazy sweep is in progress during rb_objspace_free. Adds extra protection for r46340. Patch by Vicent Marti. [Bug #10768] [ruby-core:67734] * gc.c (rb_objspace_call_finalizer): Ensure GC is c...tmm1 (Aman Karmani)
We deployed the lazy-sweep/finalizer patch to production a few days ago and have confirmed that it stopped the segfaults we have been seeing. Would you like me to commit it to trunk?tmm1 (Aman Karmani)
After some investigation, it appears the background threads in our app are unrelated to this segfault. ruby_vm_destruct will call thread_free, which sets ruby_current_thread to NULL (https://github.com/ruby/ruby/blob/v2_1_4/vm.c#L2117...tmm1 (Aman Karmani)
There are also some other threads present in this app at shutdown time, created by a c-extension as worker threads. These threads do not interact with the ruby vm directly, but instead communicate over a queue. I guess this must be relat...tmm1 (Aman Karmani)
tmm1 (Aman Karmani)12:10 AM Ruby Bug #13931: correct install_name of libruby on macOS (libruby.2.5.0.dylib -> libruby.2.5.dylib)