Issue #20300 has been reported by AMomchilov (Alexander Momchilov).
----------------------------------------
Feature #20300: Hash: set value and get pre-existing value in one call
https://bugs.ruby-lang.org/issues/20300
* Author: AMomchilov (Alexander Momchilov)
* Status: Open
----------------------------------------
When using a Hash, sometimes you want to set a new value, *and* see what was already there. Today, you **have** to do this in two steps:
```ruby
h = { k: "old value" }
# 1. Do a look-up for `:k`.
old_value = h[:k]
# 2. Do another look-up for `:k`, even though we just did that!
h[:k] = "new value"
use(old_value)
```
This requires two separate `Hash` look-ups for `:k`. This is fine for symbols, but is expensive if computing `#hash` or `#eql?` is expensive for the key. It's impossible to work around this today from pure Ruby code.
I propose adding `Hash#update_value`, which has semantics are similar to this Ruby snippet:
```ruby
class Hash
def update_value(key, new_value)
old_value = self[key]
self[key] = new_value
old_value
end
end
```
... except it'll be implemented in C, with modifications to `tbl_update` that achieves this with a hash-lookup.
Here's a PR with a PoC implementation: https://github.com/ruby/ruby/pull/10092
--
https://bugs.ruby-lang.org/
Issue #19266 has been reported by gareth (Gareth Adams).
----------------------------------------
Bug #19266: URI::Generic should use URI::RFC3986_PARSER instead of URI::DEFAULT_PARSER
https://bugs.ruby-lang.org/issues/19266
* Author: gareth (Gareth Adams)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.1.3p185 (2022-11-24 revision 1a6b16756e) [arm64-darwin21]
* Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
In June 2014, [`uri/common` was updated][1] to introduce a RFC3986-compliant parser (`URI::RFC3986_PARSER`) as an alternative to the previous RFC2396 parser, and common methods like `URI()` were updated to use that new parser by default. The only methods in `common` not updated were [`URI.extract` and `URI.regexp`][2] which are marked as obsolete. (The old parser was kept in the `DEFAULT_PARSER` constant despite it not being the default for those methods, presumably for backward compatibility.)
However, similar [methods called on `URI::Generic`][3] were never updated to use this new parser. This means that methods like `URI::Generic.build` fail when given input that succeeds normally, and this also affects subclasses like URI::HTTP:
```
$ pry -r uri -r uri/common -r uri/generic
[1] pry(main)> URI::Generic.build(host: "underscore_host.example")
URI::InvalidComponentError: bad component(expected host component): underscore_host.example
from /Users/gareth/.asdf/installs/ruby/3.1.3/lib/ruby/3.1.0/uri/generic.rb:591:in `check_host'
[2] pry(main)> URI::HTTP.build(host: "underscore_host.example")
URI::InvalidComponentError: bad component(expected host component): underscore_host.example
from /Users/gareth/.asdf/installs/ruby/3.1.3/lib/ruby/3.1.0/uri/generic.rb:591:in `check_host'
[3] pry(main)> URI("http://underscore_host.example")
=> #<URI::HTTP http://underscore_host.example>
```
`URI::Generic.new` allows a configurable `parser` positional argument to override the class' default parser, but other factory methods like `.build` don't allow this override.
Arguably this doesn't cause problems because at least in the case above, the URI can be built with the polymorphic constructor, but having the option to build URIs from explicit named parts is useful, and leaving the outdated functionality in the `Generic` class is ambiguous. It's possible that the whole Generic class and its subclasses aren't intended to be used directly how I'm intending here, but there's nothing I could see that suggested this is the case.
I'm not aware of the entire list of differences between RFC2396 and RFC3986. The relevant difference here is that in RFC2396 an individual segment of a host ([`domainlabel`s][4]) could only be `alphanum | alphanum *( alphanum | "-" ) alphanum`, whereas RFC3986 allows [hostnames][5] to include any of `ALPHA / DIGIT / "-" / "." / "_" / "~"`. It's possible that other differences might cause issues for developers, but since this has gone over 8 years without anyone else caring about this, this is definitely not especially urgent.
[1]: https://github.com/ruby/ruby/commit/bb83f32dc3e0424d25fa4e55d8ff32b061320e41
[2]: https://github.com/ruby/ruby/blob/28a17436503c3c4cb7a35b423a894b697cd80da9/…
[3]: https://github.com/ruby/ruby/blob/28a17436503c3c4cb7a35b423a894b697cd80da9/…
[4]: https://www.rfc-editor.org/rfc/rfc2396#section-3.2.2
[5]: https://www.rfc-editor.org/rfc/rfc3986#page-13
--
https://bugs.ruby-lang.org/
Issue #20050 has been reported by martinemde (Martin Emde).
----------------------------------------
Bug #20050: Segfault on Ruby 3.2.2 on x86_64 Darwin 20 (maybe in Array#hash)
https://bugs.ruby-lang.org/issues/20050
* Author: martinemde (Martin Emde)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-darwin20]
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
Hi,
In the rubygems & bundler repositories we've now had two segfaults in the same exact code within days of merging a change to that code, both on ruby 3.2.2 on darwin20.
1. https://github.com/rubygems/rubygems/actions/runs/7110489973/job/1935706778…
2. https://github.com/rubygems/rubygems/actions/runs/7131889001/job/1942130416…
The specific error seems to happen when calculating the hash of the array in Gem::NameTuple#hash. The array contents that is being `.hash`ed both times should be exactly: `["has_metadata", "1.0", "ruby"]`. If I'm reading this correctly, this indicates that the crash is related either to creating this hash or storing this hash in the hash table (I'm not quite sure which is triggering the crash).
An excerpt of the C backtrace shows the same backtrace for both crashes:
```
-- C level backtrace information -------------------------------------------
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_vm_bugreport+0x7c4) [0x10cb0f994]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_bug_for_fatal_signal+0x1d0) [0x10c9158c0]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(sigsegv+0x5b) [0x10ca609ab]
/usr/lib/system/libsystem_platform.dylib(_sigtramp+0x1d) [0x7ff810c14dfd]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_id_table_lookup+0x16) [0x10caa2a56]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(callable_method_entry_or_negative+0x5e) [0x10cae9c8e]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_check_funcall_basic_kw+0x129) [0x10caf0039]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(obj_any_hash+0x3c) [0x10c94bd2c]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(any_hash+0x52) [0x10c94bc12]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_st_add_direct+0x1d) [0x10ca69b7d]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(ar_try_convert_table+0x85) [0x10c94d015]
/Users/runner/hostedtoolcache/Ruby/3.2.2/x64/lib/libruby.3.2.dylib(rb_hash_aset+0x18f) [0x10c94e26f]
```
I'm not sure how to follow this instruction in this case on GitHub actions: "Don't forget to include the Crash Report log file under DiagnosticReports directory in bug reports."
I have not been able to reproduce this locally with the same version of ruby (but I'm on darwin22 instead of 20). I will follow up if we continue to see this same crash.
--
https://bugs.ruby-lang.org/
Issue #20102 has been reported by ioquatix (Samuel Williams).
----------------------------------------
Bug #20102: Introduce `Fiber#resuming?`
https://bugs.ruby-lang.org/issues/20102
* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
* Assignee: ioquatix (Samuel Williams)
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN
----------------------------------------
There are some tricky edge cases when using `Fibre#raise` and `Fiber#kill`, e.g.
```ruby
fiber = nil
killer = Fiber.new do
fiber.raise("Stop")
end
fiber = Fiber.new do
killer.resume
end
fiber.resume
# 4:in `raise': attempt to raise a resuming fiber (FiberError)
# 4:in `block in <main>'
```
Async has to deal with this edge case explicitly by rescuing the exception:
https://github.com/socketry/async/blob/ffd019d9c1d547926a28fe8f36bf7bfe91d8…
I'd like to avoid doing that and instead just ask "Can I kill/raise on this fiber right now?" which is determined by whether the fiber itself can be resumed or transferred to.
To address this, I'd like to introduce `Fiber#resuming?`:
```c
/*
* call-seq: fiber.resumed? -> true or false
*
* Whether the fiber is currently resumed.
*/
VALUE
rb_fiber_resuming_p(VALUE fiber_value)
{
struct rb_fiber_struct *fiber = fiber_ptr(fiber_value);
if (FIBER_TERMINATED_P(fiber)) return RUBY_Qfalse;
return RBOOL(fiber->resuming_fiber);
}
```
See the PR: https://github.com/ruby/ruby/pull/9382
--
https://bugs.ruby-lang.org/
Issue #19592 has been reported by npic1 (Nat Pic1).
----------------------------------------
Bug #19592: Unable to statically link a single extension in 3.2.x and >3.1.4
https://bugs.ruby-lang.org/issues/19592
* Author: npic1 (Nat Pic1)
* Status: Open
* Priority: Normal
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
Hi,
I need to statically link a single extension (not all of them) by adding it to ext/Setup.
This worked until version 3.1.4 and 3.2.x.
It appears that this change broke it:
[https://bugs.ruby-lang.org/projects/ruby-master/repository/git/revisions/79…
[https://github.com/ruby/ruby/pull/6756](https://github.com/ruby/ruby/pull/6….
I have attached a script to reproduce the issue.
When running the script, `ldd` fails with:
```
ext/extinit.o: in function `Init_ext':
extinit.c:(.text+0x10): undefined reference to `ruby_init_ext'
```
---Files--------------------------------
ruby_static_test.sh (1.57 KB)
--
https://bugs.ruby-lang.org/
Issue #20076 has been reported by hsbt (Hiroshi SHIBATA).
----------------------------------------
Bug #20076: M:N scheduler crashes on macOS with RUBY_MN_THREADS=1
https://bugs.ruby-lang.org/issues/20076
* Author: hsbt (Hiroshi SHIBATA)
* Status: Open
* Priority: Normal
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN
----------------------------------------
This is known issue. I already shared this to ko1.
The version of https://github.com/ruby/ruby/commit/28e3886689c71b22487dd5d0cb62f3b5ed0a77cc is crashed with `make exam`.
This is happend with webrick test on `make test-tool`.
My environment is macOS Sonoma 14.3 beta1 and
```
$ pkgutil --pkg-info=com.apple.pkg.CLTools_Executables
package-id: com.apple.pkg.CLTools_Executables
version: 15.1.0.0.1.1700200546
volume: /
location: /
install-time: 1702331495
```
--
https://bugs.ruby-lang.org/
Issue #20231 has been reported by ioquatix (Samuel Williams).
----------------------------------------
Bug #20231: Don't wait in io_binwrite_string if not necessary.
https://bugs.ruby-lang.org/issues/20231
* Author: ioquatix (Samuel Williams)
* Status: Open
* Priority: Normal
* Backport: 3.2: REQUIRED, 3.3: REQUIRED
----------------------------------------
PR: https://github.com/ruby/ruby/pull/9792
Writing to a buffered IO can result in the entire internal buffer being flushed, which causes `io_binwrite_string_internal` to return 0. In that case, we were setting `errno = EAGAIN`. This causes `rb_io_maybe_wait_writable` to be invoked, however we should immediately retry `io_binwrite_string_internal` instead.
The reason why calling `rb_io_maybe_wait_writable` is a bad idea in general, is that not all IO can go via this mechanism in every situation - in other words, `kqueue` does not support `kevent("/dev/null", writable)` and returns errno=22 `EINVAL`. The same applies to some kinds of pipes, TTYs, etc.
Indirectly responsible for <https://github.com/socketry/async/issues/301>.
--
https://bugs.ruby-lang.org/
Issue #20245 has been reported by peterzhu2118 (Peter Zhu).
----------------------------------------
Bug #20245: Crash when checking symbol encoding
https://bugs.ruby-lang.org/issues/20245
* Author: peterzhu2118 (Peter Zhu)
* Status: Open
* Priority: Normal
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: REQUIRED, 3.3: REQUIRED
----------------------------------------
GitHub PR: https://github.com/ruby/ruby/pull/9871
We sometimes pass in a fake string to sym_check_asciionly. This can crash if sym_check_asciionly raises because it creates a CFP with the fake string as the receiver which will crash if GC tries to mark the CFP.
For example, the following script crashes:
```ruby
GC.stress = true
Object.const_defined?("\xC3")
```
--
https://bugs.ruby-lang.org/
Issue #20190 has been reported by tompng (tomoya ishida).
----------------------------------------
Bug #20190: `invalid_encoding_string << number` should be valid encoding in some case, but does not
https://bugs.ruby-lang.org/issues/20190
* Author: tompng (tomoya ishida)
* Status: Open
* Priority: Normal
* ruby -v: ruby 3.4.0dev (2024-01-09T07:07:19Z master db476cc71c) [x86_64-linux]
* Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN
----------------------------------------
In some encoding, appending ascii char might change invalid encoding string to valid. But it does not.
~~~ruby
# encoding: utf-8
valid = '表'.encode('sjis')
valid.bytes
# => [0x95, 0x5c]
s = valid.byteslice(0, 1)
p s.valid_encoding? #=> false
s << 0x5c
p s == valid #=> true
p s.valid_encoding? #=> should be true, but false
~~~
pull request: https://github.com/ruby/ruby/pull/9553
--
https://bugs.ruby-lang.org/