The remote fetcher only works with certain schemes (`http`, `https`,
`s3`, and `file`). It's possible for other schemes to show up in this
code and it can cause bugs.
Before this patch, doing `gem install path:///hello` would result in an
infinite loop because this function would do `send "fetch_path"`,
calling itself forever. Now we see an exception.
I think we should validate gem names earlier, but it's really best
practice to restrict the possible strings passed to `send`.
https://github.com/rubygems/rubygems/commit/54e2781b73
remove_class_from_subclasses calls st_insert, which mallocs. Malloc is not
allowed in GC. This commit replaces the st_insert with an st_update since
we know that ns_id exists in the st_table.
The following script reproduces the crash:
require "tempfile"
Tempfile.create do |file|
ns = Namespace.new
ns.require(file)
end
The docs currently say to use `Prism.parse(foo, version: RUBY_VERSION)` for this.
By specifying "current" instead, we can have prism raise a more specifc error.
Note: Does not use `ruby_version` from `ruby/version.h` because writing a test for that is not really possible.
`RUBY_VERSION` is nicely stubbable for both the c-ext and FFI backend.
https://github.com/ruby/prism/commit/9c5cd205cf
The atomic load/store operations here should mostly be using
release/acquire semantics. This may lead to better performance than what
we had under the default seq_cst.
On x86 this may make the atomic store of hash faster, as it can avoid
xchg. On ARM the loads may be faster (depending on target CPU for the
compiler).
Reference for comparison of atomic operations
https://godbolt.org/z/6EdaMa5rG
no_rest() trips an assert inside the GC when we allocate with the GC
disabled this way:
(gc_continue) ../src/gc/default/default.c:2029
(newobj_cache_miss+0x128) [0x105040048] ../src/gc/default/default.c:2370
(rb_gc_impl_new_obj+0x7c) [0x105036374] ../src/gc/default/default.c:2482
(newobj_of) ../src/gc.c:995
(rb_method_entry_alloc+0x40) [0x1051e6c64] ../src/vm_method.c:1102
(rb_method_entry_complement_defined_class) ../src/vm_method.c:1180
(prepare_callable_method_entry+0x14c) [0x1051e87b8] ../src/vm_method.c:1728
(callable_method_entry_or_negative+0x1e8) [0x1051e809c] ../src/vm_method.c:1874
It's tries to continue the GC because it was out of space. Looks like
it's not safe to allocate new objects after using
rb_gc_disable_no_rest(); existing usages use it for malloc calls.
This is due to the way MMTK frees objects, which is on another native thread.
Due to this, there's no `ec` so we can't grab the VM Lock.
This was causing issues in release builds of MMTK on CI like:
```
/home/runner/work/ruby/ruby/build/ruby(sigsegv+0x46) [0x557905117ef6] ../src/signal.c:948
/lib/x86_64-linux-gnu/libc.so.6(0x7f555f845330) [0x7f555f845330]
/home/runner/work/ruby/ruby/build/ruby(rb_ec_thread_ptr+0x0) [0x5579051d59d5] ../src/vm_core.h:2087
/home/runner/work/ruby/ruby/build/ruby(rb_ec_ractor_ptr) ../src/vm_core.h:2036
/home/runner/work/ruby/ruby/build/ruby(rb_current_execution_context) ../src/vm_core.h:2105
/home/runner/work/ruby/ruby/build/ruby(rb_current_ractor_raw) ../src/vm_core.h:2104
/home/runner/work/ruby/ruby/build/ruby(rb_current_ractor) ../src/vm_core.h:2112
/home/runner/work/ruby/ruby/build/ruby(rb_current_ractor) ../src/vm_core.h:2110
/home/runner/work/ruby/ruby/build/ruby(vm_locked) ../src/vm_sync.c:15
/home/runner/work/ruby/ruby/build/ruby(rb_vm_lock_enter_body) ../src/vm_sync.c:141
/home/runner/work/ruby/ruby/build/ruby(rb_vm_lock_enter+0xa) [0x557905390a5a] ../src/vm_sync.h:76
/home/runner/work/ruby/ruby/build/ruby(fiber_pool_stack_release) ../src/cont.c:777
/home/runner/work/ruby/ruby/build/ruby(fiber_stack_release+0xe) [0x557905392075] ../src/cont.c:919
/home/runner/work/ruby/ruby/build/ruby(cont_free) ../src/cont.c:1087
/home/runner/work/ruby/ruby/build/ruby(fiber_free) ../src/cont.c:1180
```
This would have ran into an assertion error in a debug build but we don't run debug builds of MMTK on Github's CI.
Co-authored-by: john.hawthorn@shopify.com
- ### Problem
Running `bundle lock --add-checksums` doesn't add the checksum of
gems hosted on server that don't implement the compact index API.
This result in a lockfile which is unusable in production as
some checksums will be missing and Bundler raising an error.
Users can work around this problem by running:
`BUNDLE_LOCKFILE_CHECKSUMS=true bundle install --force`
But this means redownloading and installing all gems which isn't
great and slow on large apps.
### Context
Bundler uses the Compact Index API to get the checksum of gems,
but most private gem servers don't implement the compact index API
(such as cloudsmith or packagecloud). This results in a soft failure
on bundler side, and bundler leaving out blank checksum for those
gems.
### Solution
For gems that are hosted on private servers that don't send back
the checksum of the gem, I'd like to fallback to the
`bundle install` mechanism, which don't rely on an external API but
instead compute the checksum of the package installed on disk.
This patch goes through the spec that didn't return a checksum,
and compute one if the package exists on disk.
This solution makes the `bundle lock --add-checksums` command
actually usable in real world scenarios while keeping the
`bundle lock` command fast enough.
https://github.com/rubygems/rubygems/commit/8e9abb5472
CSV is no more part of the standard lib, but the documentation was not
updated (the example link was broken for the master branch)
Selected ERB that has the dedicated directory, like CSV.
Strictly more info than just the builtin_type from `assert_ne!`.
Old:
assertion `left != right` failed: ZJIT should only see live objects
left: 0
right: 0
New:
ZJIT saw a dead object. T_type=0, out-of-heap:0x0000000110d4bb40
Also, the new `VALUE::obj_info` is more flexible for print debugging than the
dump_info() it replaces. It now allows you to use it as part of a `format!`
string instead of always printing to stderr for you.
I don't think these methods are hotspots, and since gem specifications
are sometimes serialized to yaml / marshal, I think we should remove as
many instance variables as possible
https://github.com/rubygems/rubygems/commit/40490d918b
