Skip to content

Move Mutex init to the start of the initialisation process #3510

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
merged 1 commit into from
Sep 10, 2020
Merged

Move Mutex init to the start of the initialisation process #3510

merged 1 commit into from
Sep 10, 2020

Conversation

eightbitraptor
Copy link
Contributor

If the GC runs before the Mutex's are initialised then we get a crash in pthread_mutex_lock.

It is possible for GC to run during initialisation due to objects being allocated, for example: during InitVM_Object, and Init_VM

Logs

Here is the output of make runruby, with an empty test.rb

mattvh@tomoe ~/s/r/build [1]> make runruby
compiling ../ruby/eval.c
compiling ../ruby/gc.c
../ruby/revision.h updated
compiling ../ruby/version.c
generating vm_call_iseq_optimized.inc
vm_call_iseq_optimized.inc unchanged
linking miniruby
[BUG] pthread_mutex_lock: Invalid argument (EINVAL)
ruby 2.8.0dev (2020-06-29T19:53:08Z allocate-garbage 9fcdabf3a3) [x86_64-darwin19]

-- Crash Report log information --------------------------------------------
   See Crash Report log file under the one of following:
     * ~/Library/Logs/DiagnosticReports
     * /Library/Logs/DiagnosticReports
   for more details.
Don't forget to include the above Crash Report log file in bug reports.

-- Control frame information -----------------------------------------------
c:0002 p:---- s:0006 e:000005 CFUNC  :inherited
c:0001 p:---- s:0003 e:000002 (none) [FINISH]

[BUG] Segmentation fault at 0x0000000000000000
ruby 2.8.0dev (2020-06-29T19:53:08Z allocate-garbage 9fcdabf3a3) [x86_64-darwin19]

-- Crash Report log information --------------------------------------------
   See Crash Report log file under the one of following:
     * ~/Library/Logs/DiagnosticReports
     * /Library/Logs/DiagnosticReports
   for more details.
Don't forget to include the above Crash Report log file in bug reports.

-- Control frame information -----------------------------------------------
c:0002 p:---- s:0006 e:000005 CFUNC  :inherited
c:0001 p:---- s:0003 e:000002 (none) [FINISH]

And the backtrace

(lldb) thread backtrace
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x0)
  * frame #0: 0x0000000100323c90 miniruby`RB_FL_TEST_RAW(obj=0, flags=8192) at fl_type.h:235:25
    frame #1: 0x0000000100323c2d miniruby`RB_FL_ANY_RAW(obj=0, flags=8192) at fl_type.h:256:12
    frame #2: 0x00000001003242b8 miniruby`rbimpl_rstring_getmem(str=0) at rstring.h:127:9
    frame #3: 0x00000001003228f7 miniruby`RSTRING_PTR(str=0) at rstring.h:153:17
    frame #4: 0x00000001003206b6 miniruby`oldbt_bugreport(arg=0x00007ffeefbfdef4, file=0, line=0, method=4321210992) at vm_backtrace.c:826:51
    frame #5: 0x00000001003208cb miniruby`oldbt_iter_cfunc(ptr=0x00007ffeefbfdef8, cfp=0x0000000101319f90, mid=3969) at vm_backtrace.c:791:5
    frame #6: 0x00000001003200cb miniruby`backtrace_each(ec=0x0000000101107210, init=(miniruby`oldbt_init at vm_backtrace.c:764), iter_iseq=(miniruby`oldbt_iter_iseq at vm_backtrace.c:772), iter_cfunc=(miniruby`oldbt_iter_cfunc at vm_backtrace.c:785), arg=0x00007ffeefbfdef8) at vm_backtrace.c:540:6
    frame #7: 0x0000000100320641 miniruby`rb_backtrace_print_as_bugreport at vm_backtrace.c:849:5
    frame #8: 0x0000000100325c20 miniruby`rb_vm_bugreport(ctx=0x0000000000000000) at vm_dump.c:946:2
    frame #9: 0x0000000100337885 miniruby`rb_bug(fmt="%s: %s (%s)") at error.c:660:5
    frame #10: 0x00000001000aa9c5 miniruby`rb_bug_errno(mesg="pthread_mutex_lock", errno_arg=22) at error.c:691:13
    frame #11: 0x000000010029ba6b miniruby`rb_native_mutex_lock(lock=0x0000000101809748) at thread_pthread.c:404:2
    frame #12: 0x000000010029db65 miniruby`rb_nativethread_lock_lock(lock=0x0000000101809748) at thread.c:454:5
    frame #13: 0x000000010032affc miniruby`rb_postponed_job_flush(vm=0x0000000101809400) at vm_trace.c:1672:5
    frame #14: 0x000000010029f875 miniruby`rb_threadptr_execute_interrupts(th=0x0000000101106f80, blocking_timing=0) at thread.c:2243:6
    frame #15: 0x00000001003013a1 miniruby`rb_vm_check_ints(ec=0x0000000101107210) at vm_core.h:1822:2
    frame #16: 0x00000001002e1e08 miniruby`vm_pop_frame(ec=0x0000000101107210, cfp=0x0000000101319f90, ep=0x000000010121a028) at vm_insnhelper.c:386:5
    frame #17: 0x00000001002e1dc9 miniruby`rb_vm_pop_frame(ec=0x0000000101107210) at vm_insnhelper.c:395:5
    frame #18: 0x000000010031c2d6 miniruby`vm_call0_cfunc_with_frame(ec=0x0000000101107210, calling=0x00007ffeefbfeee0, cd=0x00007ffeefbfeed0, argv=0x00007ffeefbff030) at vm_eval.c:100:2
    frame #19: 0x000000010031b9fd miniruby`vm_call0_cfunc(ec=0x0000000101107210, calling=0x00007ffeefbfeee0, cd=0x00007ffeefbfeed0, argv=0x00007ffeefbff030) at vm_eval.c:111:12
    frame #20: 0x00000001002f394a miniruby`vm_call0_body(ec=0x0000000101107210, calling=0x00007ffeefbfeee0, cd=0x00007ffeefbfeed0, argv=0x00007ffeefbff030) at vm_eval.c:146:15
    frame #21: 0x00000001002f3724 miniruby`rb_vm_call0(ec=0x0000000101107210, recv=4321214240, id=3969, argc=1, argv=0x00007ffeefbff030, me=0x0000000101907200, kw_splat=0) at vm_eval.c:59:12
    frame #22: 0x00000001002f4169 miniruby`rb_vm_call_kw(ec=0x0000000101107210, recv=4321214240, id=3969, argc=1, argv=0x00007ffeefbff030, me=0x0000000101907200, kw_splat=0) at vm_eval.c:239:12
    frame #23: 0x000000010031c62d miniruby`rb_call0(ec=0x0000000101107210, recv=4321214240, mid=3969, argc=1, argv=0x00007ffeefbff030, call_scope=CALL_FCALL, self=8) at vm_eval.c:361:12
    frame #24: 0x00000001002f5330 miniruby`rb_call(recv=4321214240, mid=3969, argc=1, argv=0x00007ffeefbff030, scope=CALL_FCALL) at vm_eval.c:689:12
    frame #25: 0x00000001002f56e5 miniruby`rb_funcall(recv=4321214240, mid=3969, n=1) at vm_eval.c:915:12
    frame #26: 0x0000000100037acd miniruby`rb_class_inherited(super=4321214240, klass=4321376976) at class.c:710:12
    frame #27: 0x000000010003818f miniruby`rb_define_class_id_under(outer=4320184456, id=22411, super=4321214240) at class.c:832:5
    frame #28: 0x0000000100037e38 miniruby`rb_define_class_under(outer=4320184456, name="WeakMap", super=4321214240) at class.c:782:12
    frame #29: 0x00000001000da0ca miniruby`Init_GC at gc.c:12066:22
    frame #30: 0x00000001000fb1cd miniruby`rb_call_inits at inits.c:61:5
    frame #31: 0x00000001000b5e60 miniruby`ruby_setup at eval.c:91:2
    frame #32: 0x00000001000b5efd miniruby`ruby_init at eval.c:108:17
    frame #33: 0x00000001000016a8 miniruby`main(argc=2, argv=0x00007ffeefbff610) at main.c:49:2
    frame #34: 0x00007fff718dccc9 libdyld.dylib`start + 1

@eightbitraptor
If the GC runs before the Mutex's are initialised then we get a crash…
a8db42e 
… in pthread_mutex_lock.

It is possible for GC to run during initialisation due to objects being allocated
@eightbitraptor eightbitraptor force-pushed the mvh-gc-page-size-crash-boot branch from 5d5a150 to a8db42e Compare September 4, 2020 13:15
@tenderlove tenderlove merged commit ef22af4 into ruby:master Sep 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@eightbitraptor @tenderlove