[pull] master from ruby:master - #1328
Merged
Merged
Conversation
Windows applies the `longPathAware` manifest setting only when `LongPathsEnabled` is set in the registry, so paths longer than 260 characters still fail on a stock machine. Set the undocumented `IsLongPathAwareProcess` bit in the PEB at startup instead, which is what `RtlAreLongPathsEnabled` reads and what Go's runtime does since 1.23. [Bug #18947] [Bug #18923] Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`rb_w32_sysinit` is documented as being for `ruby(1)`, so a program which embeds libruby may skip it and keep the 260 character limit while `ruby.exe` does not. Call the same initialization from `ruby_setup`, which every embedder reaches through `ruby_init`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
`ruby_setup` runs for `ruby.exe` too, so calling this from `rb_w32_sysinit` as well was redundant. Nothing between the two touches a path long enough to care, including the wildcard expansion in `w32_cmdvector`, which does not expand a result over 260 characters either way. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The current `make check-depends` command completes in about 10 seconds, there is little need to run it in a separate workflow.
…tests
As documented, the #public_key methods on OpenSSL::PKey::{DH,DSA,RSA}
are obsolete, as their behavior is inconsistent and better alternatives
are available. Remove unnecessary uses from RDoc comments for other
methods.
Also add dedicated tests for these methods to confirm the current
behavior.
ruby/openssl@13d5616d17
The shape_id capacity bits come from the slot size, and the shape verifier asserts that the capacity is more than zero. The default GC satisfies this because its smallest slot is 32 bytes. MMTk allocated exact-fit slots, so an empty imemo_fields got a 16-byte slot and zero capacity bits. Boot then failed at the first class freeze: shape.c:1346: Assertion Failed: rb_shape_verify_consistency:shape_id_capacity > 0
MMTk marks objects on GC worker threads. Those threads have no execution context, so GET_EC() inside this VM_CHECK_MODE helper failed an assertion when imemo_env marking checked VM_ENV_ESCAPED_P: vm_core.h:2243: Assertion Failed: rb_current_execution_context:!expect_ec || ec != NULL
The shareable constraint checker treats a false result from rb_gc_impl_shref_marked_p as a missing shref record and raises a bug. Shref records keep an unshareable object alive past the local GC of its owner. MMTk only has a single objspace, so doesn't run local GC. So we can just assume everything is allowed to stay alive.
MMTk marks call caches on GC worker threads. Those threads have no execution context, so two debug helpers failed: * vm_cc_check_cme took the VM lock, and the lock records the current ractor. Skip the lock when the thread has no execution context. We can assume this is safe because the only threads with no EC are MMTk GC worker threads, and they're only working when the mutator is stopped. * RUBY_ASSERT_vm_locking and its variants assume the lock owner is the current ractor, but this is meaningless in a MMTk GC worker thread, so let's just pass the assertions.
ractor_mark_unshareable_parts asserts that its Ractor is not terminated. This is only relevant in the multi-objspace root scan, where a terminated Ractor has left the set and zombie_objspaces keeps its possessions alive. With a single objspace the wrapper mark function also calls this helper, and a terminated Ractor wrapper stays reachable on the heap. MMTk hits this assertion: ractor.c:259: Assertion Failed: ractor_mark_unshareable_parts:!rb_ractor_status_p(r, ractor_terminated)
The generic fields weak table callback reset the shape of a key on ST_DELETE so that the later free path skips a second table removal. A key can already be T_NONE here. MMTk debug builds zero the whole slot of a dead obj_free candidate in rb_mmtk_call_obj_free, and that work packet is unordered with this table walk: both run in the VMRefClosure bucket. When the zero wins the race, the shape write failed verification with a layout mismatch.
rb_shape_verify_consistency asserted that every checked object has room for at least one embedded field. The default GC always satisfies this because its smallest slot is 32 bytes so this assertion never fires. MMTk gives an empty imemo_fields a 16-byte slot, so its shape carries zero capacity bits, and boot failed on the first class freeze. Instead of forcing MMTk to have a minimum object size, we should just allow shapes to support a capacity of 0.
Storing the same register twice with STP is well-defined, unlike LDP, whose destination registers must be distinct. CPushPair hits this when two adjacent stack-passed arguments are the same zero immediate (both lowered to xzr, e.g. two literal false arguments) or the same register, so drop the same-register assertion from the STP encoders. The assertion was inherited from YJIT, whose backend only ever stored pairs of distinct caller-saved registers.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
6 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
See Commits and Changes for more details.
Created by
pull[bot] (v2.0.0-alpha.4)
Can you help keep this open source service alive? 💖 Please sponsor : )