ml.ruby-lang.org
Sign In Sign Up
Manage this list Sign In Sign Up

Keyboard Shortcuts

Thread View

  • j: Next unread message
  • k: Previous unread message
  • j a: Jump to all threads
  • j l: Jump to MailingList overview

ruby-dev

Thread Start a new thread
Download
Threads by month
  • ----- 2025 -----
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2024 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2023 -----
  • December
  • November
  • October
  • September
  • August
  • July
  • June
  • May
  • April
  • March
  • February
  • January
  • ----- 2022 -----
  • December
  • November
ruby-dev@ml.ruby-lang.org

  • 1 participants
  • 79 discussions
[ruby-dev:52034] [Ruby master Bug#19792] arm の alpine 上でネストしたハッシュに長い文字列を入れると segmentation fault が発生する
by koke2y 30 Sep '23

30 Sep '23
Issue #19792 has been reported by koke2y (優樹 纐纈). ---------------------------------------- Bug #19792: arm の alpine 上でネストしたハッシュに長い文字列を入れると segmentation fault が発生する https://bugs.ruby-lang.org/issues/19792 * Author: koke2y (優樹 纐纈) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) +YJIT [aarch64-linux-musl] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ## 実行環境 Docker version: Docker version 24.0.2, build cb74dfc Docker image: ruby:3.2.2-alpine3.18 ホスト環境 - chip: Apple M2 Max - OS version: Version 13.4 ## 発生した事象 上記の環境で下記のスクリプトを実行すると、segmentation faultが発生しました。 ``` str = 'a' * 100_000_000 hash = { x: { y: { z: str } } } p hash ``` ``` 81a3dc0d38e8:/api# ruby test.rb test.rb:11: [BUG] Segmentation fault at 0x0000ffff84e454a0 ruby 3.2.2 (2023-03-30 revision e51014f9c0) +YJIT [aarch64-linux-musl] -- Control frame information ----------------------------------------------- c:0006 p:---- s:0022 e:000021 CFUNC :inspect c:0005 p:---- s:0019 e:000018 CFUNC :inspect c:0004 p:---- s:0016 e:000015 CFUNC :inspect c:0003 p:---- s:0013 e:000012 CFUNC :p c:0002 p:0029 s:0008 E:001cc0 EVAL test.rb:11 [FINISH] c:0001 p:0000 s:0003 E:000da0 DUMMY [FINISH] ``` -- https://bugs.ruby-lang.org/
5 5
0 0
[ruby-dev:52045] [Ruby master Bug#19902] strftimeの返り値のascii_only?が間違っていることがある
by znz (Kazuhiro NISHIYAMA) 30 Sep '23

30 Sep '23
Issue #19902 has been reported by znz (Kazuhiro NISHIYAMA). ---------------------------------------- Bug #19902: strftimeの返り値のascii_only?が間違っていることがある https://bugs.ruby-lang.org/issues/19902 * Author: znz (Kazuhiro NISHIYAMA) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [aarch64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- ruby-jp slack で tompng さんの調査によると以下のように `Regexp.esacpe` が変になる原因は `t.ascii_only? #=> true` になっていることでした。 ``` irb(main):053> t = Time.now.strftime(u='あ') => "あ" irb(main):054> t==u => true irb(main):055> t.encoding==u.encoding => true irb(main):056> Regexp.escape(t) => "\xE3\x81\x82" irb(main):057> Regexp.escape(u) => "あ" ``` git bisect で `make miniruby && ./miniruby -ve "p Time.now.strftime('%Y年').ascii_only?"` をしつつ調べてみると、https://github.com/ruby/ruby/commit/f34280ec6b684eeb21ef3336c700… から `true` になってしまっているようです。 -- https://bugs.ruby-lang.org/
4 3
0 0
[ruby-dev:52044] [Ruby master Bug#17925] Pattern matching syntax using semicolon one-line
by kddnewton (Kevin Newton) 22 Sep '23

22 Sep '23
Issue #17925 has been updated by kddnewton (Kevin Newton). I agree with @yui-knk here, I think this is definitely a choice and at this point can't be changed. ---------------------------------------- Bug #17925: Pattern matching syntax using semicolon one-line https://bugs.ruby-lang.org/issues/17925#change-104733 * Author: koic (Koichi ITO) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- ## Summary There are the following differences between `case ... when` and` case ... in`. Is this an expected behavior? ```console % ruby -v ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] % ruby -ce 'case expression when 42; end' Syntax OK % ruby -ce 'case expression in 42; end' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! -e:1: syntax error, unexpected `end', expecting `when' case expression in 42; end ``` So, I have two concerns. - Since the pattern matching syntax is different from `case ... when`, can't user write semicolon one-line `case ... in` in the same semicolon one-line as `case ... when`? - Does `case expression in 42; end` display an experimental warning of one-line pattern matching. Right? This is reproduced in Ruby 3.1.0-dev and Ruby 3.0.1. ## Additional Information NOTE 1: I understand that only syntax that doesn't use `case` and `end` is experimental one-line pattern matching syntax. ``` % ruby -ce 'expression in 42' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! Syntax OK ``` NOTE 2: The syntax is OK if a semicolon is used between `expression` and `in`. But `case ... when` is a valid syntax to omit. ``` % ruby -e ruby -ce 'case expression; in 42; end' Syntax OK ``` -- https://bugs.ruby-lang.org/
1 0
0 0
[ruby-dev:52043] [Ruby master Bug#17925] Pattern matching syntax using semicolon one-line
by yui-knk (Kaneko Yuichiro) 04 Sep '23

04 Sep '23
Issue #17925 has been updated by yui-knk (Kaneko Yuichiro). It's possible https://github.com/yui-knk/ruby/tree/bugs_17925. I think this is not limitaion but the matter of choice. Currently `expr` is expected after `case` therefore `expression in 42` is interpreted as `expr`. For example ```ruby case expression in 42 in true in false end ``` Before the change, this is interpreted as ```ruby case (expression in 42) in true in false end ``` After the change, this is interpreted as ```ruby case expression in 42 in true in false end ``` # Impact ## For `case ... in` As shown above, this will change the behavior of current codes. Before: ```ruby expression = 42 case expression in 42 in true p :t in false p :f end #=> :t ``` ```ruby expression = 421 case expression in 42 in true p :t in false p :f end #=> :f ``` After: ```ruby expression = 42 case expression in 42 in true p :t in false p :f end #=> nothing printed, because body for 42 is empty ``` ```ruby expression = 421 case expression in 42 in true p :t in false p :f end #=> 421 (NoMatchingPatternError) # because nothing matches ``` ## For `case ... when` Before this change, this is valid ```ruby case expression in 42 when true p :t when false p :f end ``` However after this change, it's invalid ```ruby case expression in 42 when true p :t when false p :f end # test2.rb:2: syntax error, unexpected `when' (SyntaxError) # when true # ^~~~ ``` Impact on `case ... when` is inevitable because new grammar recognizes this is `case ... in` when third symbol (`in`) appears. ## New exception `expr` appears other place of the grammar. For example, `if expr ...`, `while expr ...` and so on. This change introduces an exception that you can write one line pattern matching after `if`, `unless`, `while`, `until` and so on but you can't after `case`. # Conclusion * This a matter of choice not limitaion * New grammar introduces incompatibility. It changes the behavior of `case ... in` and breaks `case ... when` * It introduces an exceptional rule to the grammar * As a reporter says, there is workaround to add `;` after `expression` `expression in 42` always returns `true` or `false` therefore it might be useless for `case`. Howerver we need to consider such impacts and benefits before decision making. # Note Impact on `case ... when` can be found as Shift/Reduce conflict. In this state, shift derives `case ... when`, on the other hand reduce derives `case ... in`. https://github.com/yui-knk/ruby/tree/bugs_17925_2 ``` State 394 shift/reduce conflict on token "`in'": 60 expr0: arg • 71 expr: arg • "`in'" @7 @8 p_top_expr_body First example: $@1 k_case arg • "`in'" @7 @8 p_top_expr_body opt_terms @19 case_body k_end "=>" @5 @6 p_top_expr_body opt_terms Shift derivation program ↳ 2: $@1 top_compstmt ↳ 3: top_stmts opt_terms ↳ 5: top_stmt ↳ 7: stmt ↳ 37: expr ↳ 68: arg "=>" @5 @6 p_top_expr_body ↳ 269: primary ↳ 358: k_case expr_value opt_terms @19 case_body k_end ↳ 78: expr ↳ 71: arg • "`in'" @7 @8 p_top_expr_body Second example: $@1 k_case arg • opt_terms "`in'" @38 @39 p_top_expr then $@40 compstmt p_cases k_end '[' opt_call_args rbracket "operator-assignment" lex_ctxt command_rhs opt_terms "end-of-input" Reduce derivation $accept ↳ 0: program "end-of-input" ↳ 2: $@1 top_compstmt ↳ 3: top_stmts opt_terms ↳ 5: top_stmt ↳ 7: stmt ↳ 32: command_asgn ↳ 41: primary_value '[' opt_call_args rbracket "operator-assignment" lex_ctxt command_rhs ↳ 377: primary ↳ 361: k_case expr_value0 opt_terms p_case_body k_end ↳ 77: expr0 ↳ 500: "`in'" @38 @39 p_top_expr then $@40 compstmt p_cases ↳ 60: arg • ``` ---------------------------------------- Bug #17925: Pattern matching syntax using semicolon one-line https://bugs.ruby-lang.org/issues/17925#change-104453 * Author: koic (Koichi ITO) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- ## Summary There are the following differences between `case ... when` and` case ... in`. Is this an expected behavior? ```console % ruby -v ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] % ruby -ce 'case expression when 42; end' Syntax OK % ruby -ce 'case expression in 42; end' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! -e:1: syntax error, unexpected `end', expecting `when' case expression in 42; end ``` So, I have two concerns. - Since the pattern matching syntax is different from `case ... when`, can't user write semicolon one-line `case ... in` in the same semicolon one-line as `case ... when`? - Does `case expression in 42; end` display an experimental warning of one-line pattern matching. Right? This is reproduced in Ruby 3.1.0-dev and Ruby 3.0.1. ## Additional Information NOTE 1: I understand that only syntax that doesn't use `case` and `end` is experimental one-line pattern matching syntax. ``` % ruby -ce 'expression in 42' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! Syntax OK ``` NOTE 2: The syntax is OK if a semicolon is used between `expression` and `in`. But `case ... when` is a valid syntax to omit. ``` % ruby -e ruby -ce 'case expression; in 42; end' Syntax OK ``` -- https://bugs.ruby-lang.org/
1 0
0 0
[ruby-dev:52042] [Ruby master Bug#17925] Pattern matching syntax using semicolon one-line
by kddnewton (Kevin Newton) 25 Aug '23

25 Aug '23
Issue #17925 has been updated by kddnewton (Kevin Newton). This is interesting. It surfaces and incompatibility we have. I didn't realize Ruby didn't allow this, so YARP allows `case expression in 42; end` to parse as expected by the OP here. If `parse.y` can't support this, I will need to explicitly disallow this in YARP. ---------------------------------------- Bug #17925: Pattern matching syntax using semicolon one-line https://bugs.ruby-lang.org/issues/17925#change-104372 * Author: koic (Koichi ITO) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- ## Summary There are the following differences between `case ... when` and` case ... in`. Is this an expected behavior? ```console % ruby -v ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] % ruby -ce 'case expression when 42; end' Syntax OK % ruby -ce 'case expression in 42; end' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! -e:1: syntax error, unexpected `end', expecting `when' case expression in 42; end ``` So, I have two concerns. - Since the pattern matching syntax is different from `case ... when`, can't user write semicolon one-line `case ... in` in the same semicolon one-line as `case ... when`? - Does `case expression in 42; end` display an experimental warning of one-line pattern matching. Right? This is reproduced in Ruby 3.1.0-dev and Ruby 3.0.1. ## Additional Information NOTE 1: I understand that only syntax that doesn't use `case` and `end` is experimental one-line pattern matching syntax. ``` % ruby -ce 'expression in 42' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! Syntax OK ``` NOTE 2: The syntax is OK if a semicolon is used between `expression` and `in`. But `case ... when` is a valid syntax to omit. ``` % ruby -e ruby -ce 'case expression; in 42; end' Syntax OK ``` -- https://bugs.ruby-lang.org/
1 0
0 0
[ruby-dev:52041] [Ruby master Bug#17925] Pattern matching syntax using semicolon one-line
by nobu (Nobuyoshi Nakada) 25 Aug '23

25 Aug '23
Issue #17925 has been updated by nobu (Nobuyoshi Nakada). I thought it a trade-off. To allow the statement, one-line pattern matching is not allowed there. But it returns `true`/`false` only and may be useless for `case`. ---------------------------------------- Bug #17925: Pattern matching syntax using semicolon one-line https://bugs.ruby-lang.org/issues/17925#change-104322 * Author: koic (Koichi ITO) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- ## Summary There are the following differences between `case ... when` and` case ... in`. Is this an expected behavior? ```console % ruby -v ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] % ruby -ce 'case expression when 42; end' Syntax OK % ruby -ce 'case expression in 42; end' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! -e:1: syntax error, unexpected `end', expecting `when' case expression in 42; end ``` So, I have two concerns. - Since the pattern matching syntax is different from `case ... when`, can't user write semicolon one-line `case ... in` in the same semicolon one-line as `case ... when`? - Does `case expression in 42; end` display an experimental warning of one-line pattern matching. Right? This is reproduced in Ruby 3.1.0-dev and Ruby 3.0.1. ## Additional Information NOTE 1: I understand that only syntax that doesn't use `case` and `end` is experimental one-line pattern matching syntax. ``` % ruby -ce 'expression in 42' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! Syntax OK ``` NOTE 2: The syntax is OK if a semicolon is used between `expression` and `in`. But `case ... when` is a valid syntax to omit. ``` % ruby -e ruby -ce 'case expression; in 42; end' Syntax OK ``` -- https://bugs.ruby-lang.org/
1 0
0 0
[ruby-dev:52040] [Ruby master Bug#17925] Pattern matching syntax using semicolon one-line
by jeremyevans0 (Jeremy Evans) 24 Aug '23

24 Aug '23
Issue #17925 has been updated by jeremyevans0 (Jeremy Evans). @kddnewton Is this possible to fix in YARP? @yui-knk Is this possible to fix in parse.y/lrama? ---------------------------------------- Bug #17925: Pattern matching syntax using semicolon one-line https://bugs.ruby-lang.org/issues/17925#change-104311 * Author: koic (Koichi ITO) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- ## Summary There are the following differences between `case ... when` and` case ... in`. Is this an expected behavior? ```console % ruby -v ruby 3.1.0dev (2021-05-28T16:34:27Z master e56ba6231f) [x86_64-darwin19] % ruby -ce 'case expression when 42; end' Syntax OK % ruby -ce 'case expression in 42; end' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! -e:1: syntax error, unexpected `end', expecting `when' case expression in 42; end ``` So, I have two concerns. - Since the pattern matching syntax is different from `case ... when`, can't user write semicolon one-line `case ... in` in the same semicolon one-line as `case ... when`? - Does `case expression in 42; end` display an experimental warning of one-line pattern matching. Right? This is reproduced in Ruby 3.1.0-dev and Ruby 3.0.1. ## Additional Information NOTE 1: I understand that only syntax that doesn't use `case` and `end` is experimental one-line pattern matching syntax. ``` % ruby -ce 'expression in 42' -e:1: warning: One-line pattern matching is experimental, and the behavior may change in future versions of Ruby! Syntax OK ``` NOTE 2: The syntax is OK if a semicolon is used between `expression` and `in`. But `case ... when` is a valid syntax to omit. ``` % ruby -e ruby -ce 'case expression; in 42; end' Syntax OK ``` -- https://bugs.ruby-lang.org/
1 0
0 0
[ruby-dev:52038] [Ruby master Bug#8782] Don't set rl_getc_function on editline
by jeremyevans0 (Jeremy Evans) 22 Aug '23

22 Aug '23
Issue #8782 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Assigned to Closed Backport deleted (1.9.3: UNKNOWN, 2.0.0: UNKNOWN) Readline support was removed in commit:59fd67fc3d405e529e038172e769ff20a8fb5535. If this is still an issue, please file it upstream https://github.com/ruby/readline-ext ---------------------------------------- Bug #8782: Don't set rl_getc_function on editline https://bugs.ruby-lang.org/issues/8782#change-104205 * Author: naruse (Yui NARUSE) * Status: Closed * Priority: Normal * Assignee: kouji (Kouji Takao) * ruby -v: ruby 2.1.0dev (2013-08-12 trunk 42528) [x86_64-darwin12.4.0] ---------------------------------------- r42402 以来 OS X 等の editline 環境では #define rl_getc(f) EOF が使われるようになってしまって残念なことになっていたわけですが、 そもそも editline の readline wrapper は non ASCII に対応していません。 (editline 自体には UTF-8 のみの対応が入ったが、readline wrapper は src/readline.c の _getc_function を経由するので non ASCII は化ける) ので、いっそ rl_getc_function を使わないようにしてはどうでしょう。 以下のようなパッチを当てると、readline なしの OS X の irb で日本語が使えるようになります。 diff --git a/ext/readline/extconf.rb b/ext/readline/extconf.rb index 0b121c1..bc0ee77 100644 --- a/ext/readline/extconf.rb +++ b/ext/readline/extconf.rb @@ -94,4 +94,5 @@ readline.have_func("clear_history") readline.have_func("rl_redisplay") readline.have_func("rl_insert_text") readline.have_func("rl_delete_text") +readline.have_func("el_init") create_makefile("readline") diff --git a/ext/readline/readline.c b/ext/readline/readline.c index 0f76d1a..85109f0 100644 --- a/ext/readline/readline.c +++ b/ext/readline/readline.c @@ -130,12 +130,7 @@ static VALUE readline_instream; static VALUE readline_outstream; #if defined HAVE_RL_GETC_FUNCTION - -#ifndef HAVE_RL_GETC -#define rl_getc(f) EOF -#endif - -static int readline_getc(FILE *); +# ifndef HAVE_EL_INIT static int readline_getc(FILE *input) { @@ -187,6 +182,7 @@ readline_getc(FILE *input) #endif return FIX2INT(c); } +# endif #elif defined HAVE_RL_EVENT_HOOK #define BUSY_WAIT 0 @@ -1771,7 +1767,9 @@ Init_readline() /* libedit check rl_getc_function only when rl_initialize() is called, */ /* and using_history() call rl_initialize(). */ /* This assignment should be placed before using_history() */ +# ifndef HAVE_EL_INIT rl_getc_function = readline_getc; +# endif #elif defined HAVE_RL_EVENT_HOOK rl_event_hook = readline_event; #endif -- https://bugs.ruby-lang.org/
1 0
0 0
[ruby-dev:52033] [Ruby master Bug#14387] Ruby 2.5 を Alpine Linux で実行すると比較的浅めで SystemStackError 例外になる
by ojab (ojab ojab) 01 Jan '23

01 Jan '23
Issue #14387 has been updated by ojab (ojab ojab). Any update on this? ---------------------------------------- Bug #14387: Ruby 2.5 を Alpine Linux で実行すると比較的浅めで SystemStackError 例外になる https://bugs.ruby-lang.org/issues/14387#change-100931 * Author: koshigoe (Masataka SUZUKI) * Status: Open * Priority: Normal * ruby -v: ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux-musl] * Backport: 2.3: DONTNEED, 2.4: DONTNEED, 2.5: REQUIRED ---------------------------------------- CircleCI で Alpine Linux を使って Ruby 2.5.0 で Rubocop を実行した時に遭遇した例外です(Ruby 2.4.3 では発生しませんでした)。 Ruby のバージョンによって、再帰が止められるまでの回数に大きな違いがあるのはなぜでしょうか? これは、意図された挙動なのか、Ruby の変更によるものでは無く Alpine Linux 固有の問題なのか、教えていただく事は可能でしょうか? Alpine Linux の Tread stack size が比較的小さい事で、Ruby 2.5.0 からこのような挙動になったのでしょうか? https://wiki.musl-libc.org/functional-differences-from-glibc.html#Thread-st… ## 再現 問題の再現のため、以下の様な再帰するコードを実行します。 ~~~ ruby # test.rb n = 100000 res = {} 1.upto(n).to_a.inject(res) do |r, i| r[i] = {} end def f(x) x.each_value { |v| f(v) } end f(res) ~~~ Ruby 2.4.3 で実行した場合、 10061 levels で例外があがりました。 ~~~ % docker container run \ -v (pwd):/mnt/my --rm \ ruby:2.4.3-alpine3.7 \ ruby -v /mnt/my/test.rb ruby 2.4.3p205 (2017-12-14 revision 61247) [x86_64-linux-musl] /mnt/my/test.rb:9:in `each_value': stack level too deep (SystemStackError) from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:9:in `block in f' from /mnt/my/test.rb:9:in `each_value' from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:9:in `block in f' from /mnt/my/test.rb:9:in `each_value' from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:9:in `block in f' ... 10061 levels... from /mnt/my/test.rb:9:in `block in f' from /mnt/my/test.rb:9:in `each_value' from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:12:in `<main>' ``` 一方で Ruby 2.5.0 で実行した場合、 134 level で例外があがりました。 ``` % docker container run \ -v (pwd):/mnt/my --rm \ test/ruby:trunk-alpine3.7 \ ruby -v /mnt/my/test.rb ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux-musl] /mnt/my/test.rb:9:in `each_value': stack level too deep (SystemStackError) from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:9:in `block in f' from /mnt/my/test.rb:9:in `each_value' from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:9:in `block in f' from /mnt/my/test.rb:9:in `each_value' from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:9:in `block in f' ... 134 levels... from /mnt/my/test.rb:9:in `block in f' from /mnt/my/test.rb:9:in `each_value' from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:12:in `<main>' ``` また、Ruby trunk で実行した場合は 2.5.0 同等の結果になりました。 ``` ruby 2.6.0dev (2018-01-24 trunk 62017) [x86_64-linux-musl] /mnt/my/test.rb:9:in `each_value': stack level too deep (SystemStackError) from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:9:in `block in f' from /mnt/my/test.rb:9:in `each_value' from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:9:in `block in f' from /mnt/my/test.rb:9:in `each_value' from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:9:in `block in f' ... 134 levels... from /mnt/my/test.rb:9:in `block in f' from /mnt/my/test.rb:9:in `each_value' from /mnt/my/test.rb:9:in `f' from /mnt/my/test.rb:12:in `<main>' ``` ※ trunk の Docker イメージを作った際の Dockerfile は以下。 https://gist.github.com/koshigoe/509be02a3580cdfc7a2cc45a4e6e44c5 ---Files-------------------------------- 0001-thread_pthread.c-make-get_main_stack-portable-on-lin.patch (2.61 KB) -- https://bugs.ruby-lang.org/
1 0
0 0
[ruby-dev:52032] [Ruby master Bug#18024] Ractor crashes when connections are closed in multiple Ractors
by niku (niku _) 27 Dec '22

27 Dec '22
Issue #18024 has been updated by niku (niku _). I also couldn't reproduce it on m2 mac with both ruby versions 3.0.0 which is reported and 3.2.0 the latest. I hope it helps. ``` ~/src/confirm_bugs.ruby-lang.org/18024 () asdf local ruby 3.0.0 ~/src/confirm_bugs.ruby-lang.org/18024 () ruby --version ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [arm64-darwin22] ~/src/confirm_bugs.ruby-lang.org/18024 () ruby description.rb <internal:ractor>:267: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. "Starting a sender" "Worker|0 Data: yay" "Worker|0 Data: yay" "Worker|0 Data: yay" "Worker|1 Data: yay" "Worker|1 Data: yay" "Worker|1 Data: yay" "Worker|0 Data: yay" "Worker|0 Data: yay" "Worker|1 Data: yay" "Worker|0 Data: yay" ^C<internal:ractor>:694:in `take': Interrupt from description.rb:35:in `block in <main>' from description.rb:35:in `each' from description.rb:35:in `<main>' ~/src/confirm_bugs.ruby-lang.org/18024 () asdf local ruby 3.2.0 ~/src/confirm_bugs.ruby-lang.org/18024 () ruby --version ruby 3.2.0 (2022-12-25 revision a528908271) [arm64-darwin22] ~/src/confirm_bugs.ruby-lang.org/18024 () ruby description.rb description.rb:9: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. "Starting a sender" "Worker|0 Data: yay" "Worker|0 Data: yay" "Worker|0 Data: yay" "Worker|0 Data: yay" "Worker|0 Data: yay" "Worker|1 Data: yay" "Worker|0 Data: yay" "Worker|1 Data: yay" "Worker|1 Data: yay" "Worker|0 Data: yay" ^C<internal:ractor>:698:in `take': Interrupt from description.rb:35:in `block in <main>' from description.rb:35:in `each' from description.rb:35:in `<main>' ``` ---------------------------------------- Bug #18024: Ractor crashes when connections are closed in multiple Ractors https://bugs.ruby-lang.org/issues/18024#change-100818 * Author: tagomoris (Satoshi TAGOMORI) * Status: Assigned * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [arm64-darwin20] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- When multiple Ractors will accept and close connections, that script caused the crash shown below. This pattern is taken when we want to distribute the overhead of `accept` to multiple CPU cores. Script: ``` require 'socket' try_times = 10 worker_num = 2 listener = TCPServer.new("127.0.0.1", 8228) listener.listen(100) workers = worker_num.times.map do |i| Ractor.new(i, listener.dup) do |index, sock| while conn = sock.accept begin data = conn.read p "Worker|#{index} Data: #{data}" conn.close rescue => e p "Worker|#{index} #{e.full_message}" end end rescue => e $stderr.puts "Error, worker#{index}: #{e.full_message}" end end p "Starting a sender" sender = Ractor.new(try_times) do |tries| tries.times.each do s = TCPSocket.new("127.0.0.1", 8228) s.write("yay") ensure s.close rescue nil end end sender.take workers.each{|w| w.take} p "End" ``` Crash report: ``` <internal:ractor>:267: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. "Starting a sender" "Worker|1 Data: yay" snippets/ractor_accept.rb:30: [BUG] Bus Error at 0x00000014000001f5 ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [arm64-darwin20] -- 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:0006 p:---- s:0023 e:000022 CFUNC :close c:0005 p:0028 s:0019 e:000017 BLOCK snippets/ractor_accept.rb:30 [FINISH] c:0004 p:---- s:0014 e:000013 CFUNC :times c:0003 p:---- s:0011 e:000010 CFUNC :each c:0002 p:0008 s:0007 e:000006 BLOCK snippets/ractor_accept.rb:26 [FINISH] c:0001 p:---- s:0003 e:000002 (none) [FINISH] -- Ruby level backtrace information ---------------------------------------- snippets/ractor_accept.rb:26:in `block in <main>' snippets/ractor_accept.rb:26:in `each' snippets/ractor_accept.rb:26:in `times' snippets/ractor_accept.rb:30:in `block (2 levels) in <main>' snippets/ractor_accept.rb:30:in `close' -- Other runtime information ----------------------------------------------- * Loaded script: snippets/ractor_accept.rb * Loaded features: 0 enumerator.so 1 thread.rb 2 rational.so 3 complex.so 4 ruby2_keywords.rb 5 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 6 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/trans/transdb.bundle 7 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/rbconfig.rb 8 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/compatibility.rb 9 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/defaults.rb 10 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/deprecate.rb 11 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/errors.rb 12 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/exceptions.rb 13 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/basic_specification.rb 14 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/stub_specification.rb 15 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/text.rb 16 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/user_interaction.rb 17 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/specification_policy.rb 18 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/util/list.rb 19 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/platform.rb 20 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/version.rb 21 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/requirement.rb 22 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/specification.rb 23 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/util.rb 24 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/dependency.rb 25 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/core_ext/kernel_gem.rb 26 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/monitor.bundle 27 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/monitor.rb 28 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/core_ext/kernel_require.rb 29 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/core_ext/kernel_warn.rb 30 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems.rb 31 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/rubygems/path_support.rb 32 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/version.rb 33 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/core_ext/name_error.rb 34 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/levenshtein.rb 35 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/jaro_winkler.rb 36 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/spell_checker.rb 37 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/spell_checkers/name_error_checkers/class_name_checker.rb 38 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/spell_checkers/name_error_checkers/variable_name_checker.rb 39 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/spell_checkers/name_error_checkers.rb 40 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/spell_checkers/method_name_checker.rb 41 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/spell_checkers/key_error_checker.rb 42 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/spell_checkers/null_checker.rb 43 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/tree_spell_checker.rb 44 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/spell_checkers/require_path_checker.rb 45 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean/formatters/plain_formatter.rb 46 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/did_you_mean.rb 47 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/socket.bundle 48 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/io/wait.bundle 49 /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/socket.rb * Process memory map: 1042f8000-1042fc000 r-x /Users/tagomoris/.rbenv/versions/3.0.0/bin/ruby 1042fc000-104300000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/bin/ruby 104300000-104304000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/bin/ruby 104304000-104308000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/bin/ruby 104308000-104310000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104310000-104314000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104314000-104318000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104318000-10431c000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 10431c000-104320000 --- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104320000-104328000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104328000-10432c000 --- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 10432c000-104330000 --- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104330000-104338000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104338000-10433c000 --- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 10433c000-104340000 --- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104340000-104348000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104348000-10434c000 --- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 10434c000-104350000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104350000-104354000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104354000-104394000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104394000-104398000 r-x /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 104398000-10439c000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 10439c000-1043a0000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 1043a0000-1043a4000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/encdb.bundle 1043a4000-1043a8000 r-x /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/trans/transdb.bundle 1043a8000-1043ac000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/trans/transdb.bundle 1043ac000-1043b0000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/trans/transdb.bundle 1043b0000-1043b4000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/enc/trans/transdb.bundle 1043b4000-1043b8000 r-x /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/monitor.bundle 1043b8000-1043bc000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/monitor.bundle 1043bc000-1043c0000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/monitor.bundle 1043c0000-1043c4000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/monitor.bundle 1043c4000-1043e8000 r-x /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/socket.bundle 1043e8000-1043ec000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/socket.bundle 1043ec000-1043f0000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/socket.bundle 1043f0000-104400000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/socket.bundle 104400000-104404000 r-x /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/io/wait.bundle 104404000-104408000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/io/wait.bundle 104408000-10440c000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/io/wait.bundle 10440c000-104410000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/ruby/3.0.0/arm64-darwin20/io/wait.bundle 104568000-1045e8000 r-x /usr/lib/dyld 1045e8000-1045f0000 r-- /usr/lib/dyld 1045f0000-1045f4000 rw- /usr/lib/dyld 1045f4000-104628000 rw- /usr/lib/dyld 104628000-10466c000 r-- /usr/lib/dyld 10466c000-104670000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/libruby.3.0.dylib 104670000-104974000 r-x /Users/tagomoris/.rbenv/versions/3.0.0/lib/libruby.3.0.dylib 104974000-10497c000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/libruby.3.0.dylib 10497c000-104980000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/libruby.3.0.dylib 104980000-10498c000 rw- /Users/tagomoris/.rbenv/versions/3.0.0/lib/libruby.3.0.dylib 10498c000-104a7c000 r-- /Users/tagomoris/.rbenv/versions/3.0.0/lib/libruby.3.0.dylib 104a7c000-104a80000 --- 104a80000-104b24000 rw- 104b24000-104b28000 --- 104b28000-104bcc000 rw- 104bcc000-104bd0000 --- 104bd0000-104c74000 rw- 104c74000-104c78000 --- 104c78000-104d1c000 rw- 104d1c000-104d20000 --- 104d20000-104dc4000 rw- 104dc4000-104dc8000 --- 104dc8000-104e6c000 rw- 104e6c000-104e70000 --- 104e70000-104f14000 rw- 104f14000-104f18000 --- 104f18000-104fbc000 rw- 104fbc000-104fc0000 --- 104fc0000-105064000 rw- 105064000-105068000 --- 105068000-10510c000 rw- 10510c000-105110000 --- 105110000-1051b4000 rw- 1051b4000-1051b8000 --- 1051b8000-10525c000 rw- 10525c000-105260000 --- 105260000-105304000 rw- 105304000-105308000 --- 105308000-1053ac000 rw- 1053ac000-1053b0000 --- 1053b0000-105454000 rw- 105454000-105458000 --- 105458000-1054fc000 rw- 1054fc000-105500000 --- 105500000-1055a4000 rw- 1055a4000-1055a8000 --- 1055a8000-10564c000 rw- 10564c000-105650000 --- 105650000-1056f4000 rw- 1056f4000-1056f8000 --- 1056f8000-10579c000 rw- 10579c000-1057a0000 --- 1057a0000-105844000 rw- 105844000-105848000 --- 105848000-1058ec000 rw- 1058ec000-1058f0000 --- 1058f0000-105994000 rw- 105994000-105998000 --- 105998000-105a3c000 rw- 105a3c000-105a40000 --- 105a40000-105ae4000 rw- 105ae4000-105ae8000 --- 105ae8000-105b8c000 rw- 105b8c000-105b90000 --- 105b90000-105c34000 rw- 105c34000-105c38000 --- 105c38000-105cdc000 rw- 105cdc000-105ce0000 --- 105ce0000-105d84000 rw- 105d84000-105d88000 --- 105d88000-105e2c000 rw- 105e2c000-105e30000 --- 105e30000-105ed4000 rw- 105ed4000-105ed8000 --- 105ed8000-105f7c000 rw- 131e00000-131f00000 rw- 132000000-132800000 rw- 132800000-133000000 rw- 138000000-138800000 rw- 138800000-139000000 rw- 139000000-139800000 rw- 139800000-13a000000 rw- 13a000000-13a800000 rw- 13a800000-13b000000 rw- 13b000000-13b800000 rw- 13b800000-13c000000 rw- 13c000000-13c800000 rw- 13c800000-13d000000 rw- 13d000000-13d800000 rw- 13d800000-13e000000 rw- 13e000000-13e800000 rw- 13e800000-13f000000 rw- 13f000000-13f800000 rw- 13f800000-140000000 rw- 141e00000-141f00000 rw- 141f00000-142000000 rw- 142000000-142800000 rw- 148000000-148800000 rw- 148800000-149000000 rw- 149000000-149800000 rw- 149800000-14a000000 rw- 14a000000-14a800000 rw- 14a800000-14b000000 rw- 14b000000-14b800000 rw- 14b800000-14c000000 rw- 14c000000-14c800000 rw- 14c800000-14d000000 rw- 14d000000-14d800000 rw- 14d800000-14e000000 rw- 14e000000-14e800000 rw- 14e800000-14f000000 rw- 14f000000-14f800000 rw- 14f800000-150000000 rw- 151e00000-151f00000 rw- 151f00000-152000000 rw- 152000000-152800000 rw- 152800000-153000000 rw- 153000000-155000000 rw- 155000000-155004000 rw- 155100000-155200000 rw- 158000000-158800000 rw- 158800000-159000000 rw- 159000000-159800000 rw- 159800000-15a000000 rw- 15a000000-15a800000 rw- 15a800000-15b000000 rw- 15b000000-15b800000 rw- 15b800000-15c000000 rw- 15c000000-15c800000 rw- 15c800000-15d000000 rw- 15d000000-15d800000 rw- 15d800000-15e000000 rw- 15e000000-15e800000 rw- 15e800000-15f000000 rw- 15f000000-15f800000 rw- 15f800000-160000000 rw- 167b08000-16b30c000 --- 16b30c000-16bb08000 rw- 16bb08000-16bb0c000 --- 16bb0c000-16bb94000 rw- 16bb94000-16bb98000 --- 16bb98000-16bda0000 rw- 16bda0000-16bda4000 --- 16bda4000-16bfac000 rw- 16bfac000-16bfb0000 --- 16bfb0000-16c1b8000 rw- 180000000-190000000 r-- 190000000-1a0000000 r-- 1a0000000-1b0000000 r-- 1b0000000-1c0000000 r-- 1c0000000-1d0000000 r-- 1d0000000-1e0000000 r-- 1e0000000-1e6000000 r-- 1e6000000-1e6e2c000 r-- 1e6e2c000-1e8000000 rw- 1e8000000-1f0000000 r-- 1f0000000-1f2000000 r-- 1f2000000-1f2bcc000 r-- 1f2bcc000-1f4864000 rw- 1f4864000-1f6000000 r-- 1f6000000-1f6864000 r-- 1f6864000-1fa57c000 r-- 1fa57c000-1fc000000 r-- 1fc000000-200000000 r-- 200000000-210000000 r-- 210000000-220000000 r-- 220000000-230000000 r-- 230000000-240000000 r-- 240000000-250000000 r-- 250000000-260000000 r-- 260000000-270000000 r-- 270000000-280000000 r-- fc0000000-1000000000 --- 1000000000-7000000000 --- [IMPORTANT] Don't forget to include the Crash Report log file under DiagnosticReports directory in bug reports. Abort trap: 6 ``` ---Files-------------------------------- ruby_2021-07-06-231613_Moris-Macbook-Air.crash (35.9 KB) ruby_2021-08-24-203317_Moris-Macbook-Air.crash (17.4 KB) -- https://bugs.ruby-lang.org/
1 0
0 0
  • ← Newer
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • Older →

HyperKitty Powered by HyperKitty version 1.3.12.