From: takashikkbn@... Date: 2018-10-22T23:44:52+00:00 Subject: [ruby-core:89516] [Ruby trunk Bug#14867][Closed] Process.wait can wait for MJIT compiler process Issue #14867 has been updated by k0kubun (Takashi Kokubun). Status changed from Assigned to Closed Thanks for your quick response. > 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. Sometimes (1) mjit_copy_job_handler could be also called and it causes a problem. But in such a case, at lest memcpy appears on the SEGV, and in this stack trace memcpy is not called but (2) `tokadd_string()` which seems not called inside mjit_copy_job_handler is called. So, if the problem is only (1), your patch ~~~ - while (!job->finish_p && !stop_worker_p) { + while (!job->finish_p) { ~~~ could work, but at the same time this patch is an invert of r65299 r65300 r65301. As stop_worker blocks until MJIT worker is stopped and MJIT worker blocks until the postponed job is flushed with your patch (because you skip to stopping on stop_worker_p), that results in dead lock. So, for (1), I'll check stop_worker_p inside mjit_copy_job_handler and skip everything if it's being stopped. I think that wouldn't have a race condition as long as RUBY_VM_CHECK_INTS is called only when stop_worker_p is already set to TRUE in ruby_cleanup situation. > Not sure if removing interrupt checking here is right, either. > We want to ensure Ctrl-C works during shutdown. I understood the intention of the code. I want to support that too. Since (2) could be just a side effect of (1) failure (I'm not sure), let me try fixing (1) first, and let's see whether (2) is fixed by that or not. Thanks. ---------------------------------------- Bug #14867: Process.wait can wait for MJIT compiler process https://bugs.ruby-lang.org/issues/14867#change-74569 * Author: k0kubun (Takashi Kokubun) * Status: Closed * Priority: Normal * Assignee: normalperson (Eric Wong) * Target version: * ruby -v: * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- If Ruby tries to wait for any child process, MJIT's gcc/clang process could be caught by the method call. It's not convenient for both Ruby's user and MJIT worker thread, so Process.wait and its families should somehow avoid waiting for it. ---Files-------------------------------- 0001-hijack-SIGCHLD-handler-for-internal-use.patch (13.8 KB) JIT-test-all.log (39.9 KB) mjit_test-all_63796.log (40.4 KB) config_ruby-loco_mingw.log (27 KB) test_jit_results.txt (41.2 KB) -- https://bugs.ruby-lang.org/ Unsubscribe: