ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: s.wanabe@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:92550] [Ruby trunk Bug#15821] ruby_process_options() may cause "WB miss (O->Y)"
Date: Sun, 05 May 2019 10:38:19 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-77911.20190505103818.d97b0f55baf17cc8@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-15821.20190504054225@ruby-lang.org

Issue #15821 has been updated by wanabe (_ wanabe).


ko1 (Koichi Sasada) wrote:
> it is local problem on it?

I guess, no. It is not a local problem.
It will cause by `RARRAY_ASET` with shared array.

> or all of `rb_ary_replace()` calls have the same issue?

Not only `rb_ary_replace()` has the issue but also the array.c functions that call `ary_make_shared()` do.
For example, `rb_ary_aref()` == `Array#[]` can calls `ary_make_shared()` when Range or 2 args are passed.

But I guess "`RARRAY_ASET` with shared array" pattern is rare case.
Most cases in array.c use `ARY_SET` macro that has `assert(!ARY_SHARED_P(a))` guard.
Other cases in ruby repository are not able to be "shared array" AFAIK.
For example, enum.c has `RARRAY_ASET(data->buf, data->n*2, v)` but `data->buf` can't be shared array.

C extensions may have the issue.
For example:

```
static VAUE foo(VALUE self, VALUE ary) {
  RARRAY_ASET(ary, 0, rb_str_new("foo", 3));
  return Qnil;
}

void Init_foo {
  rb_define_method(cFoo, "foo", foo, 1);
}
```

`Foo#foo` may cause "WB miss (O->Y)" when old shared array is given.

----------------------------------------
Bug #15821: ruby_process_options() may cause "WB miss (O->Y)"
https://bugs.ruby-lang.org/issues/15821#change-77911

* Author: wanabe (_ wanabe)
* Status: Open
* Priority: Normal
* Assignee: 
* Target version: 
* ruby -v: ruby 2.7.0dev (2019-05-04 trunk b72623012d) [x86_64-linux]
* Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN
----------------------------------------
## Problem

Ruby interpreter may cause error "WB miss (O->Y)" on some conditions that are `RGENGC_CHECK_MODE=5` and `RUBY_DEBUG=gc_stress`

## How to reproduce

1. build ruby with high RGENGC_CHECK_MODE
   * `make ruby optflags="-O3 -DRGENGC_CHECK_MODE=5"`
2. run ruby with gc_stress
   * `RUBY_DEBUG=gc_stress ./ruby --disable-gems -ve 1`

## Probable cause

1. `rb_construct_expanded_load_path` calls `rb_ary_replace(vm->load_path_snapshot, vm->load_path)`.
2. It creates shared root array and makes `vm->load_path` SHARED_ARRAY.
3. After a while, `process_options` calls `RARRAY_ASET(load_path, i, path)`.
4. It calls `rb_gc_writebarrier` -> `gc_writebarrier_generational`.
   * Incremental mark phase is finished because of `RUBY_DEBUG=gc_stress`.
5. It makes `vm->load_path` remembered, but not shared root array!
6. "WB miss (O->Y)" is done.
   * Old parent is shared root array.
   * New child is `path` of above 3.

## Proposal

How about call `rb_ary_modify` before `RARRAY_SET` in `process_options`?
Or using `rb_ary_store` instead of `RARRAY_SET` may avoid the error.

## Sample output

An example of full output is attached.
(Sorry, I GZipped it because of file-size limitation)
The snippet is here:

```
ruby 2.7.0dev (2019-05-04 trunk b72623012d) [x86_64-linux]
verify_internal_consistency_reachable_i: WB miss (O->Y) 0x000055c3262f3610 [3LM   ] T_ARRAY [   ] len: 20, capa:2 ptr:0x000055c326498380 -> 0x000055c3262f3908 [2  P  ] T_STRING (String) /home/wanabe/.rbenv/versions/trunk/lib/ruby/site_ruby/2.7.0
[all refs] (size: 5307)
(snip)
[allrefs_dump_i] 0x000055c3263349f8 [3LMP  ] T_ARRAY [E ] len: 0 (embed) <- <0x000055c326336f28 [0  P U] VM/thread (Thread) VM/thread>
./ruby: [BUG] Segmentation fault at 0x0000000000000010
ruby 2.7.0dev (2019-05-04 trunk b72623012d) [x86_64-linux]

-- Control frame information -----------------------------------------------
c:0001 p:0000 s:0003 E:0022c0 (none) [FINISH]


-- Machine register context ------------------------------------------------
 RIP: 0x000055c32452e15a RBP: 0x0000000000000001 RSP: 0x00007ffea126d470
 RAX: 0x0000000000000000 RBX: 0x000055c3262ef3c8 RCX: 0x0000000000000001
 RDX: 0x000055c324773446 RDI: 0x00007ff8c77cb680 RSI: 0x0000000000000001
  R8: 0x000055c3262ef3b8  R9: 0x0000000000000018 R10: 0x0000000000000018
 R11: 0x0000000000000246 R12: 0x0000000000000100 R13: 0x0000000000000005
 R14: 0x000055c3262f3c28 R15: 0x000055c3262ef1b0 EFL: 0x0000000000010206

-- C level backtrace information -------------------------------------------
/home/wanabe/work/prog/ruby/ruby/tmp/trunk/ruby(rb_vm_bugreport+0x554) [0x55c324769fa4] ../../vm_dump.c:715
[0x55c324760088]
/home/wanabe/work/prog/ruby/ruby/tmp/trunk/ruby(sigsegv+0x42) [0x55c324640d42] ../../signal.c:997
/lib/x86_64-linux-gnu/libpthread.so.0(__restore_rt+0x0) [0x7ff8c797ff40]
/home/wanabe/work/prog/ruby/ruby/tmp/trunk/ruby(allrefs_dump+0x1a) [0x55c32452e15a] /usr/include/x86_64-linux-gnu/bits/stdio2.h:100
[0x55c32453a478]
[0x55c32453a64c]
[0x55c32453f874]
/home/wanabe/work/prog/ruby/ruby/tmp/trunk/ruby(rb_str_dup+0x29) [0x55c32465aa59] ../../string.c:722
[0x55c32463f2e1]
/home/wanabe/work/prog/ruby/ruby/tmp/trunk/ruby(ruby_process_options+0xc0) [0x55c3246404a0] ../../ruby.c:2380
/home/wanabe/work/prog/ruby/ruby/tmp/trunk/ruby(ruby_options+0xca) [0x55c32451e1ea] ../../eval.c:118
/home/wanabe/work/prog/ruby/ruby/tmp/trunk/ruby(main+0x67) [0x55c324519ec7] ../../main.c:42
(snip)
Aborted (core dumped)
```

---Files--------------------------------
out.log.gz (114 KB)


-- 
https://bugs.ruby-lang.org/

  parent reply	other threads:[~2019-05-05 10:38 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-15821.20190504054225@ruby-lang.org>
2019-05-04  5:42 ` [ruby-core:92537] [Ruby trunk Bug#15821] ruby_process_options() may cause "WB miss (O->Y)" s.wanabe
2019-05-05  4:25 ` [ruby-core:92541] " ko1
2019-05-05  9:58 ` [ruby-core:92548] " lourens
2019-05-05 10:38 ` s.wanabe [this message]
2019-05-21 13:56 ` [ruby-core:92744] " nobu
2019-05-22  8:35 ` [ruby-core:92774] " ko1
2019-07-31 14:32 ` [ruby-core:94076] [Ruby master " nagachika00
2019-08-26 15:02 ` [ruby-core:94569] " usa

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-77911.20190505103818.d97b0f55baf17cc8@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).