February 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:112203] [Ruby master Bug#19051] Incorrect pointers in global_cc_cache_table when compacting

by eightbitraptor (Matthew Valentine-House)

Issue #19051 has been updated by eightbitraptor (Matthew Valentine-House). Fixed in [PR#7236](https://github.com/ruby/ruby/pull/7236) ---------------------------------------- Bug #19051: Incorrect pointers in global_cc_cache_table when compacting https://bugs.ruby-lang.org/issues/19051#change-101636 * Author: eightbitraptor (Matthew Valentine-House) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- [Github PR 6531](https://github.com/ruby/ruby/pull/6531) During auto-compaction, T_IMEMO objects get moved around the heap. `vm->The global_cc_cache_table` is an array of pointers to callcache objects, stored as T_IMEMO's of type callcache on the GC heap. These pointers are never updated during the update references step of compaction. If the T_IMEMO object gets moved and another object allocated in the same slot, then the contents of the `global_cc_cache_table` will be incorrect, resulting in a crash when attempting to access it. An example of this is during the mark phase when we attempt to check the validity of the callcache entry before marking it, but the object is not actually a callcache. ``` -- C level backtrace information ------------------------------------------- /usr/local/ruby/bin/ruby(rb_print_backtrace+0x11) [0x5610067b325e] vm_dump.c:759 /usr/local/ruby/bin/ruby(rb_vm_bugreport) vm_dump.c:1045 /usr/local/ruby/bin/ruby(rb_bug_for_fatal_signal+0xec) [0x5610068603bc] error.c:821 /usr/local/ruby/bin/ruby(sigsegv+0x4d) [0x561006706d9d] signal.c:964 /lib/x86_64-linux-gnu/libpthread.so.0(__restore_rt+0x0) [0x7f87ce6ea420] /usr/local/ruby/bin/ruby(vm_cc_invalidated_p+0x4) [0x5610067acb84] vm_callinfo.h:369 /usr/local/ruby/bin/ruby(rb_vm_mark) vm.c:2652 /usr/local/ruby/bin/ruby(gc_mark_roots+0x55) [0x5610065f4305] gc.c:7180 /usr/local/ruby/bin/ruby(gc_marks_start+0x13) [0x5610065f6450] gc.c:7852 /usr/local/ruby/bin/ruby(gc_marks) gc.c:8149 ``` -- https://bugs.ruby-lang.org/

1 year, 3 months

1
0
0 0

[ruby-core:112201] [Ruby master Bug#18755] Backport rubygems/pull/5154 into Ruby 3.0

by hsbt (Hiroshi SHIBATA)

Issue #18755 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Open to Closed Thanks for clarification. I'll backport https://github.com/rubygems/rubygems/pull/5154 and release RubyGems 3.2.34 with it. ---------------------------------------- Bug #18755: Backport rubygems/pull/5154 into Ruby 3.0 https://bugs.ruby-lang.org/issues/18755#change-101634 * Author: vo.x (Vit Ondruch) * Status: Closed * Priority: Normal * ruby -v: ruby 3.0.4p208 (2022-04-12 revision 3fa771dded) [x86_64-linux] * Backport: 2.7: DONTNEED, 3.0: REQUIRED, 3.1: DONTNEED ---------------------------------------- Please backport [RubyGems PR#5154](https://github.com/rubygems/rubygems/pull/5044). Fedora is still affected by this issue: https://bodhi.fedoraproject.org/updates/FEDORA-2022-8cf0124add @deivid Not sure you are going to release RubyGems 3.2.34 due to this. -- https://bugs.ruby-lang.org/

1 year, 3 months

1
0
0 0

[ruby-core:112199] [Ruby master Bug#18755] Backport rubygems/pull/5154 into Ruby 3.0

by vo.x (Vit Ondruch)

Issue #18755 has been updated by vo.x (Vit Ondruch). hsbt (Hiroshi SHIBATA) wrote in #note-3: > @vo.x Is your request https://github.com/rubygems/rubygems/pull/5154? Your link is https://github.com/rubygems/rubygems/pull/5044, not 5154. I'm confusing now. Sorry for confusion. This is the correct ticket: https://github.com/rubygems/rubygems/pull/5154 as referenced here: https://src.fedoraproject.org/rpms/ruby/blob/f35/f/ruby.spec#_164 The 5044 is cause of the troubles. Not sure how I mixed it up. ---------------------------------------- Bug #18755: Backport rubygems/pull/5154 into Ruby 3.0 https://bugs.ruby-lang.org/issues/18755#change-101633 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.0.4p208 (2022-04-12 revision 3fa771dded) [x86_64-linux] * Backport: 2.7: DONTNEED, 3.0: REQUIRED, 3.1: DONTNEED ---------------------------------------- Please backport [RubyGems PR#5154](https://github.com/rubygems/rubygems/pull/5044). Fedora is still affected by this issue: https://bodhi.fedoraproject.org/updates/FEDORA-2022-8cf0124add @deivid Not sure you are going to release RubyGems 3.2.34 due to this. -- https://bugs.ruby-lang.org/

1 year, 3 months

1
0
0 0

[ruby-core:112198] [Ruby master Bug#18755] Backport rubygems/pull/5154 into Ruby 3.0

by hsbt (Hiroshi SHIBATA)

Issue #18755 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Closed to Open @vo.x You require is https://github.com/rubygems/rubygems/pull/5154 ? Your link is https://github.com/rubygems/rubygems/pull/5044, not 5154. I'm confusing now. ---------------------------------------- Bug #18755: Backport rubygems/pull/5154 into Ruby 3.0 https://bugs.ruby-lang.org/issues/18755#change-101632 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 3.0.4p208 (2022-04-12 revision 3fa771dded) [x86_64-linux] * Backport: 2.7: DONTNEED, 3.0: REQUIRED, 3.1: DONTNEED ---------------------------------------- Please backport [RubyGems PR#5154](https://github.com/rubygems/rubygems/pull/5044). Fedora is still affected by this issue: https://bodhi.fedoraproject.org/updates/FEDORA-2022-8cf0124add @deivid Not sure you are going to release RubyGems 3.2.34 due to this. -- https://bugs.ruby-lang.org/

1 year, 3 months

1
0
0 0

[ruby-core:112193] [Ruby master Bug#19405] Prevent Use of include CustomModule in a Nested Class

by kyonides

Issue #19405 has been reported by kyonides (Edwin Acuña). ---------------------------------------- Bug #19405: Prevent Use of include CustomModule in a Nested Class https://bugs.ruby-lang.org/issues/19405 * Author: kyonides (Edwin Acuña) * Status: Open * Priority: Normal * ruby -v: ruby 2.7.5p203 (2021-11-24 revision f69aeb8314) [x86_64-linux-gnu] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Bug present ever since **Ruby 1.8**. Tested in **Ruby 2.7 and 3.0** as well. I would like to request the developers to prevent any person from doing something as illogical and useless as the code I have provided you with right below. ``` ruby module MyModule class MyClass A = 'A' B = 'B' include MyModule end end ``` If you print something like: ``` ruby puts MyModule::MyClass::MyClass::MyClass::MyClass::MyClass::MyClass::MyClass::MyClass::MyClass::MyClass::MyClass::MyClass::MyClass::MyClass::MyClass::MyClass::B ``` Ruby will let you do it! Why is it possible to chain the calls to MyClass class forever and ever? It should throw an error for including the very same module and class where the constants are nested. Proposed Error Class: "ModuleError: Class nested in module %s cannot call include method to add the same module." Or something the like. =_=¡ -- https://bugs.ruby-lang.org/

1 year, 3 months

2
1
0 0

[ruby-core:112185] [Ruby master Bug#19402] CSV skip_lines option not behaving as documented

by jamie_ca (Jamie Macey)

Issue #19402 has been reported by jamie_ca (Jamie Macey). ---------------------------------------- Bug #19402: CSV skip_lines option not behaving as documented https://bugs.ruby-lang.org/issues/19402 * Author: jamie_ca (Jamie Macey) * Status: Open * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-darwin21] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- The [CSV documentation](https://ruby-doc.org/stdlib-3.1.0/libdoc/csv/rdoc/CSV.html#c… for the `skip_lines` parser option says "If a String, converts it to a Regexp, ignores lines that match it." Application behaviour as well as [the source](https://github.com/ruby/csv/blob/master/lib/csv/parser.rb#L909-L919) appears to be normalizing the string encoding and running a simple substring check instead. Given the existing behaviour, this might just want a documentation update to describe it accurately? I stumbled across this on a project still on ruby 2.6.9 ([2.6 docs](https://ruby-doc.org/stdlib-2.6.1/libdoc/csv/rdoc/CSV.html#method-c-n…), but it's applicable still at 3.2.0. Reproduction script: ```ruby require 'csv' data = <<CSV data,data test,data data,test CSV puts "Parsing with regexp skip_lines /^test/, expect 2 rows" CSV.parse(data, skip_lines: /^test/).each { |row| pp row } puts puts "Parsing with text skip_lines \"^test\", expect 2 rows" CSV.parse(data, skip_lines: "^test").each { |row| pp row } puts puts "Parsing with unanchored text skip_lines \"test\", expect 1 row" CSV.parse(data, skip_lines: "test").each { |row| pp row } puts ``` ``` $ ruby csv_test.rb Parsing with regexp skip_lines /^test/, expect 2 rows ["data", "data"] ["data", "test"] Parsing with text skip_lines "^test", expect 2 rows ["data", "data"] ["test", "data"] ["data", "test"] Parsing with unanchored text skip_lines "test", expect 1 row ["data", "data"] ``` -- https://bugs.ruby-lang.org/

1 year, 3 months

3
2
0 0

[ruby-core:112166] [Ruby master Bug#19397] ruby -h fails with SIGSGV if ulimit -s is any else than unlimited

by john_d_s (John Damm Soerensen)

Issue #19397 has been reported by john_d_s (John Damm Soerensen). ---------------------------------------- Bug #19397: ruby -h fails with SIGSGV if ulimit -s is any else than unlimited https://bugs.ruby-lang.org/issues/19397 * Author: john_d_s (John Damm Soerensen) * Status: Open * Priority: Normal * ruby -v: ruby 3.3.0dev (2023-01-30T23:43:40Z master 7439ccf0ed) [x86_64-linux] * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This applies to all versions of ruby. I have tried these 2.6.3 2.6.6 2.7.2 3.0.0 3.2.0 To reproduce simply set ulimit -s to anything other than unlimited. Then run ruby -h (or any other invocation of ruby) and ruby will generate a SIGSEGV and core dump. The stack trace from gdb shows that ruby has failed in reserve_stack line 1022 (for the latest from github) gdb ruby core.11885 ..... Core was generated by `./ruby -h'. Program terminated with signal 11, Segmentation fault. #0 reserve_stack (limit=0x7e9a5f4400e0 <Address 0x7e9a5f4400e0 out of bounds>, limit@entry=0x7fffffffe000 "l=38;5;13:*.xcf=38;5;13:*.xwd=38;5;13:*.yuv=38;5;13:*.cgm=38;5;13:*.emf=38;5;13:*.axv=38;5;13:*.anx=38;5;13:*.ogv=38;5;13:*.ogx=38;5;13:*.aac=38;5;45:*.au=38;5;45:*.flac=38;5;45:*.mid=38;5;45:*.midi=3"..., size=1535999991552, size@entry=1535999995904) at thread_pthread.c:1022 1022 limit[0] = 0; .... -- https://bugs.ruby-lang.org/

1 year, 3 months

3
6
0 0

[ruby-core:111146] [Ruby master Bug#19172] `ruby_thread_has_gvl_p` is innacurate sometimes -- document or change?

by ivoanjo (Ivo Anjo)

Issue #19172 has been reported by ivoanjo (Ivo Anjo). ---------------------------------------- Bug #19172: `ruby_thread_has_gvl_p` is innacurate sometimes -- document or change? https://bugs.ruby-lang.org/issues/19172 * Author: ivoanjo (Ivo Anjo) * Status: Open * Priority: Normal * ruby -v: (All Ruby versions) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- Howdy 👋! I work for Datadog [on the ddtrace gem](https://github.com/DataDog/dd-trace-rb) and I found a... sharp edge on the internal `ruby_thread_has_gvl_p` API. I am aware that `ruby_thread_has_gvl_p` is documented an experimental API that is exported as a symbol but not present on the VM include files. ### Background In the ddtrace profiling component, we setup a signal handler and then periodically send SIGPROF signals to try to interrupt the running Ruby thread (e.g. the thread that is holding the global VM lock or equivalent). In the signal handler, we need to perform some API calls which are not safe to do without the GVL. So we need to check if the signal handler got called in the thread that has the GVL. ### The issue ```ruby int ruby_thread_has_gvl_p(void) { rb_thread_t *th = ruby_thread_from_native(); if (th && th->blocking_region_buffer == 0) { return 1; } else { return 0; } } ``` In its current implementation, `ruby_thread_has_gvl_p` only checks if the thread has a `blocking_region_buffer` or not. Unfortunately, this means that when called from a thread that lost the GVL but not due to blocking (e.g. via `rb_thread_schedule()`), it can still claim that a thread is holding the GVL when that is not the case. I ran into this issue in https://github.com/DataDog/dd-trace-rb/pull/2415, and needed to find a workaround. ### Next steps Since this is an internal VM API, I'm not sure you'd want to change the current behavior, so I was thinking of perhaps two options: * Is it worth changing `ruby_thread_has_gvl_p` to be accurate in the case I've listed? * If not, would you accept a PR to document its current limitations, so that others don't run into the same issue I did? -- https://bugs.ruby-lang.org/

1 year, 3 months

2
2
0 0

[ruby-core:112161] [Ruby master Bug#19396] Backport RubyGems 3.4.6 and Bundler 2.4.6 to ruby_3_2

by hsbt (Hiroshi SHIBATA)

Issue #19396 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #19396: Backport RubyGems 3.4.6 and Bundler 2.4.6 to ruby_3_2 https://bugs.ruby-lang.org/issues/19396 * Author: hsbt (Hiroshi SHIBATA) * Status: Closed * Priority: Normal * Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED ---------------------------------------- RubyGems 3.4.6 fixed `Gem::Ext::CargoBuilder`. https://github.com/ruby/ruby/pull/7214 -- https://bugs.ruby-lang.org/

1 year, 3 months

2
1
0 0

[ruby-core:112160] [Ruby master Misc#19096] [Question] Time with `-00:00` offset is in UTC

by duerst

Issue #19096 has been updated by duerst (Martin Dürst). I'm not sure whether and how much this is relevant, but please note that the Sedate WG in the IETF has a draft (https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-07.html, close to final) that updates RFC 3339 (https://www.rfc-editor.org/rfc/rfc3339). For details, please check https://www.ietf.org/archive/id/draft-ietf-sedate-datetime-extended-07.html…. ---------------------------------------- Misc #19096: [Question] Time with `-00:00` offset is in UTC https://bugs.ruby-lang.org/issues/19096#change-101597 * Author: andrykonchin (Andrew Konchin) * Status: Closed * Priority: Normal ---------------------------------------- It's a bit unexpected but ```ruby Time.new(2022, 1, 1, 0, 0, 0, "-00:00").utc? # => true ``` But time with `+00:00` or `0` offset is treated as not UTC time: ```ruby Time.new(2022, 1, 1, 0, 0, 0, "+00:00").utc? # => false Time.new(2022, 1, 1, 0, 0, 0, 0).utc? # => false ``` Is it an intentional behaviour? In this case could you please clarify the reason why it works this way? --- ``` ruby -v ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) ``` -- https://bugs.ruby-lang.org/

1 year, 3 months

1
0
0 0

2024

2023

2022

ruby-core February 2023