MiniRacer hangs after fork

[SamSaffron]

@cataphract / @nightpool previous versions of mini_racer were fork friendly ... but now sadly it looks like we totally stall after forks due to a GC thread.

Repro is:

  def test_forking
    trigger_gc = lambda do
      ctx = MiniRacer::Context.new
      ctx.eval("var a = #{('x' * 100000).inspect}")
      ctx.eval("a = undefined")
      ctx.isolate.low_memory_notification
    end
    trigger_gc.call
    Process.wait fork { trigger_gc.call }
  end

Any ideas how we can sort this out?

[SamSaffron]

Posted on v8 users here:

https://groups.google.com/g/v8-users/c/sosbtZ49m3U

[SamSaffron]

Backtrace:

(gdb) bt
#0  0x00007f18d4fb202d in pthread_cond_signal@@GLIBC_2.3.2 () from /usr/lib/libpthread.so.0
#1  0x00007f18d084a5fc in v8::platform::DelayedTaskQueue::Append(std::unique_ptr<v8::Task, std::default_delete<v8::Task> >) ()
   from /home/sam/Source/mini_racer/lib/mini_racer_extension.so
#2  0x00007f18d0849db0 in v8::platform::DefaultWorkerThreadsTaskRunner::PostTask(std::unique_ptr<v8::Task, std::default_delete<v8::Task> >) () from /home/sam/Source/mini_racer/lib/mini_racer_extension.so
#3  0x00007f18d0848f51 in v8::platform::DefaultPlatform::CallOnWorkerThread(std::unique_ptr<v8::Task, std::default_delete<v8::Task> >) () from /home/sam/Source/mini_racer/lib/mini_racer_extension.so
#4  0x00007f18d1014653 in v8::internal::ConcurrentMarking::ScheduleTasks() ()
   from /home/sam/Source/mini_racer/lib/mini_racer_extension.so
#5  0x00007f18d09732ab in v8::internal::MarkCompactCollector::MarkLiveObjects() ()
   from /home/sam/Source/mini_racer/lib/mini_racer_extension.so
#6  0x00007f18d0972bb1 in v8::internal::MarkCompactCollector::CollectGarbage() ()
   from /home/sam/Source/mini_racer/lib/mini_racer_extension.so
#7  0x00007f18d09468ea in v8::internal::Heap::MarkCompact() () from /home/sam/Source/mini_racer/lib/mini_racer_extension.so
#8  0x00007f18d0943389 in v8::internal::Heap::PerformGarbageCollection(v8::internal::GarbageCollector, v8::GCCallbackFlags) ()
   from /home/sam/Source/mini_racer/lib/mini_racer_extension.so
#9  0x00007f18d0940f10 in v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) () from /home/sam/Source/mini_racer/lib/mini_racer_extension.so
#10 0x00007f18d094141e in v8::internal::Heap::CollectAllAvailableGarbage(v8::internal::GarbageCollectionReason) ()
   from /home/sam/Source/mini_racer/lib/mini_racer_extension.so
#11 0x00007f18d087cdec in v8::Isolate::LowMemoryNotification() () from /home/sam/Source/mini_racer/lib/mini_racer_extension.so
#12 0x00007f18d08445f6 in rb_isolate_low_memory_notification (self=94876640147440)
    at ../../../../ext/mini_racer_extension/mini_racer_extension.cc:783

[lloeki]

Looks like a similar problem here:

WARNING: V8 isolate was forked, it can not be disposed and memory will not be reclaimed till the Ruby process exits.
/app/vendor/bundle/ruby/2.7.0/gems/parallel-1.19.2/lib/parallel.rb:445: [BUG] Segmentation fault at 0x00007f8521f109d0
ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux]

-- C level backtrace information -------------------------------------------

/app/vendor/ruby-2.7.1/bin/../lib/libruby.so.2.7(rb_vm_bugreport+0x7ce) [0x7f8582a4402e] vm_dump.c:755
/app/vendor/ruby-2.7.1/bin/../lib/libruby.so.2.7(rb_bug_for_fatal_signal+0xe7) [0x7f8582863207] error.c:658
/app/vendor/ruby-2.7.1/bin/../lib/libruby.so.2.7(sigsegv+0x4b) [0x7f85829a807b] signal.c:946
/lib/x86_64-linux-gnu/libc.so.6(0x7f85823e5fd0) [0x7f85823e5fd0]
/lib/x86_64-linux-gnu/libpthread.so.0(__GI___pthread_timedjoin_ex+0x28) [0x7f8581f73bd8]
/app/vendor/bundle/ruby/2.7.0/gems/sq_mini_racer-0.2.5.0.1.beta3/lib/sq_mini_racer_extension.so(_ZN2v88platform12WorkerThreadD0Ev+0x1c) [0x7f85232b945c]
/app/vendor/bundle/ruby/2.7.0/gems/sq_mini_racer-0.2.5.0.1.beta3/lib/sq_mini_racer_extension.so(0x7f85232b777e) [0x7f85232b777e]
/app/vendor/bundle/ruby/2.7.0/gems/sq_mini_racer-0.2.5.0.1.beta3/lib/sq_mini_racer_extension.so(0x7f85232b666a) [0x7f85232b666a]
/app/vendor/bundle/ruby/2.7.0/gems/sq_mini_racer-0.2.5.0.1.beta3/lib/sq_mini_racer_extension.so(0x7f85232b683e) [0x7f85232b683e]
/lib/x86_64-linux-gnu/libc.so.6(0x7f85823ea0f1) [0x7f85823ea0f1]
/lib/x86_64-linux-gnu/libc.so.6(0x431ea) [0x7f85823ea1ea]
/app/vendor/ruby-2.7.1/bin/../lib/libruby.so.2.7(ruby_stop+0x10) [0x7f8582870cc0] eval.c:290
/app/vendor/ruby-2.7.1/bin/../lib/libruby.so.2.7(ruby_run_node) (null):0
/app/vendor/ruby-2.7.1/bin/../lib/libruby.so.2.7(rb_f_fork+0x74) [0x7f85829576e4] process.c:4130
/app/vendor/ruby-2.7.1/bin/../lib/libruby.so.2.7(vm_call_cfunc_with_frame+0xc9) [0x7f8582a206ba] vm_insnhelper.c:2514

[SamSaffron]

FYI, v8 are implementing a single threaded version of platform to resolve this, we would like to make this optional in mini_racer (pending this landing in v8)

https://chromium-review.googlesource.com/c/v8/v8/+/2416501/3

We need to build a custom version of v8 to test and make a PR to mini racer that exposes the new interface to opt for "single threaded mode" on platform.

[tisba]

This sounds a bit like the behaviour we are seeing as well in #170.

[chaffeqa]

looks like the single threaded version got merged, did that make it into min_racer yet?

[SamSaffron]

@chaffeqa I think we need to wait on libv8 8.9 for this, I can't find it in the 8.8 changelog

[SamSaffron]

This is now working as of latest commit, see:

https://github.com/rubyjs/mini_racer/blob/master/test/test_forking.rb