summaryrefslogtreecommitdiff
path: root/thread_pthread.c
diff options
context:
space:
mode:
authornagachika <nagachika@ruby-lang.org>2021-06-03 20:46:53 +0900
committernagachika <nagachika@ruby-lang.org>2021-06-03 20:46:53 +0900
commit2dd18df4a35a4b2dd0cf2dec7759898246fc6935 (patch)
tree9ec562b07900603960bc76f0ab7c669b9b281dba /thread_pthread.c
parent9680ee97e0b3e87c0fc9a65c01de1ee50a1a178b (diff)
merge revision(s) 86c262541ad07528842d76dab4b9b34bd888d5f4,7e14762159643b4415e094f9d2a90afaf7994588: [Backport #17935]
Fix a race condition around mjit_recompile This fixes SEGVs like https://github.com/ruby/ruby/runs/2715166621?check_suite_focus=true. When mjit_recompile is called when mjit_compile is compiling the exact same iseq (and after it called mjit_capture_cc_entries), iseq->body->jit_unit is re-created and its cc_entries becomes NULL. Then, when it tries to lookup cc_entries through iseq->body->jit_unit, it fails. --- mjit.c | 21 +++++++++++++-------- mjit_worker.c | 4 ++++ 2 files changed, 17 insertions(+), 8 deletions(-) Do not doubly hold an MJIT lock This is a follow-up of 86c262541ad07528842d76dab4b9b34bd888d5f4. CRITICAL_SECTION_START/FINISH are not needed when it's called from an MJIT worker. Also, ZALLOC needs to be calloc because ZALLOC may trigger GC, which an MJIT worker must not do. --- mjit.c | 23 ++++++++++++++--------- mjit_worker.c | 4 ++-- 2 files changed, 16 insertions(+), 11 deletions(-)
Diffstat (limited to 'thread_pthread.c')
0 files changed, 0 insertions, 0 deletions