ruby-core

```
takashikkbn@gmail.com wrote:
> @normalperson You added `RUBY_VM_CHECK_INTS(ec)` in mjit.c's `stop_worker()` on r63855, but that seems to randomly cause SEGV like this:

OK, investigating...

> /usr/home/hsbt/chkbuild/tmp/build/20181022T153002Z/ruby/ruby(sigsegv) (null):0
> /lib/libthr.so.3(0x801fb3954) [0x801fb3954]
> /lib/libthr.so.3(0x801fb2eb2) [0x801fb2eb2]
> [0x7ffffffff193]
> /usr/home/hsbt/chkbuild/tmp/build/20181022T153002Z/ruby/ruby(tokadd_escape+0x140b73) [0x802dfc916] parse.y:5510
> /usr/home/hsbt/chkbuild/tmp/build/20181022T153002Z/ruby/ruby(tokadd_string) parse.y:5717
> /usr/home/hsbt/chkbuild/tmp/build/20181022T153002Z/ruby/ruby(rb_postponed_job_flush+0x12d) [0x127737d] vm_trace.c:1655

So rb_postponed_job_flush is calling mjit_copy_job_handler?  I'm
not sure how we're entering the parser from
rb_postponed_job_flush, actually.

If mjit_copy_job_handler is the culprit, maybe having
mjit_copy_job go out-of-scope from mjit-worker while main thread
is using the copy job is wrong.  So maybe we need to remove
stop_worker_p check from worker, here:

--- a/mjit_worker.c
+++ b/mjit_worker.c
@@ -1182,7 +1182,7 @@ copy_cache_from_main_thread(struct mjit_copy_job *job)
         return FALSE;
 
     CRITICAL_SECTION_START(3, "in MJIT copy job wait");
-    while (!job->finish_p && !stop_worker_p) {
+    while (!job->finish_p) {
         rb_native_cond_wait(&mjit_worker_wakeup, &mjit_engine_mutex);
         verbose(3, "Getting wakeup from client");
     }

Otherwise, the Ruby thread will SEGV because mjit_copy_job goes
out-of-scope in mjit_worker.

> /usr/home/hsbt/chkbuild/tmp/build/20181022T153002Z/ruby/ruby(rb_threadptr_execute_interrupts+0x81) [0x1218a61] thread.c:2134
> /usr/home/hsbt/chkbuild/tmp/build/20181022T153002Z/ruby/ruby(stop_worker+0xcb) [0x1134bdb] ./vm_core.h:1773
> /usr/home/hsbt/chkbuild/tmp/build/20181022T153002Z/ruby/ruby(mjit_finish) mjit.c:726
> /usr/home/hsbt/chkbuild/tmp/build/20181022T153002Z/ruby/ruby(ruby_finalize_1+0x0) [0x10d829b] eval.c:236
> /usr/home/hsbt/chkbuild/tmp/build/20181022T153002Z/ruby/ruby(ruby_cleanup) eval.c:238
> /usr/home/hsbt/chkbuild/tmp/build/20181022T153002Z/ruby/ruby(main+0x72) [0x104be92] ./main.c:42
> ~~~
> 
> https://rubyci.org/logs/rubyci.s3.amazonaws.com/freebsd11zfs/ruby-trunk/log/20181022T153002Z.fail.html.gz
> 
> I think `rb_threadptr_execute_interrupts()` is designed to be called in safe places on VM and calling it from `ruby_cleanup()` may not be expected. Could you remove `RUBY_VM_CHECK_INTS()` from the `stop_worker()` and try to solve the original issue in another way?

Not sure if removing interrupt checking here is right, either.
We want to ensure Ctrl-C works during shutdown.

Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>