Since enabling YJIT or MJIT drastically changes what could go wrong at
runtime, it's good to be front and center about whether they are enabled
when dumping a crash report. Previously, `RUBY_DESCRIPTION` and the
description printed when crashing can be different when a JIT is on.
Introduce a new internal data global, `rb_dynamic_description`, and set
it to be the same as `RUBY_DESCRIPTION` during initialization; use it
when crashing.
* version.c: Init_ruby_description(): Initialize and use
`rb_dynamic_description`.
* error.c: Change crash reports to use `rb_dynamic_description`.
* ruby.c: Call `Init_ruby_description()` earlier. Slightly more work
for when we exit right after printing the description but that
was deemed acceptable.
* include/ruby/version.h: Talk about how JIT info is not in
`ruby_description`.
* test/-ext-/bug_reporter/test_bug_reporter.rb: Remove handling for
crash description being different from `RUBY_DESCRIPTION`.
* test/ruby/test_rubyoptions.rb: ditto
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
Co-authored-by: Alan Wu <alanwu@ruby-lang.org>
I suspect that sometimes on CI the last thread is prempted before eaching the exit hook
causing the test to flake. I can't find a good way to force it to run.
This commit is to skip a failure with annocheck 10.76 on the annocheck test
case on the CI. Previously The test worked with annocheck 10.73.
The issue was reported at <https://bugs.ruby-lang.org/issues/18061#note-24>.
> Hardened: ruby: MAYB: test: gaps because no notes found
> Hardened: ruby: info: For more information visit: https://sourceware.org/annobin/annobin.html/Test-gaps.html
It seems that the annocheck added the gaps test at 10.76. Maybe the upstream commit is below.
The annocheck is a part of the annobin project: https://sourceware.org/annobin/
```
$ git clone git://sourceware.org/git/annobin.git
$ git show 61184ae1180a134bfbbd125e9fe339baedd67c18
commit 61184ae1180a134bfbbd125e9fe339baedd67c18
Author: Nick Clifton <nickc@redhat.com>
Date: Mon Jun 13 16:56:46 2022 +0100
Annocheck: Add TEST_GAPS. Add MAYB for TEST_NOTES if DWARF info could not be found
...
```
The paths for extensions of gems would contain the hardcoded ruby
version on which the extension was built. This will replace it with
runtime ruby version like the parent version directory. It will make the
standalone script compatible between different ruby version installations.
https://github.com/rubygems/rubygems/commit/a9dae93d5d
I was looking at (yet another) flamegraph in speedscope, and used the
'left hand heavy' and was shocked to realize that 0.5s of the 1.7s
is spent in DepProxy#name. This method _only_ delegates the name to an
underlying spec, so it's not complex at all.
It seems to be of how often this line ends up calling it:
next if handled.any?{|d| d.name == dep.name && (match_current_platform || d.__platform == dep.__platform) } || dep.name == "bundler"
The `handled` array is built up as dependencies are handled, so this get
slower as more dependencies are installed.
This change changes how `handled` is track. Instead of just an array, I've
tried using a Hash, with the key being a dep's name, and the value being
a list of deps with that name. This means it's constant time to find
the dependencies with the same name.
I saw a drop from 1.7s to 1.0s against master, and from 0.95s to 0.24s
when used with https://github.com/rubygems/rubygems/pull/5533https://github.com/rubygems/rubygems/commit/844dac30d4
The GC compaction mechanism implements a kind of read barrier by marking
some (OS) pages as unreadable, and installing a SIGBUS/SIGSEGV handler
to detect when they're accessed and invalidate an attempt to move the
object.
Unfortunately, when a debugger is attached to the Ruby interpreter on
Mac OS, the debugger will trap the EXC_BAD_ACCES mach exception before
the runtime can transform that into a SIGBUS signal and dispatch it.
Thus, execution gets stuck; any attempt to continue from the debugger
re-executes the line that caused the exception and no forward progress
can be made.
This makes it impossible to debug either the Ruby interpreter or a C
extension whilst compaction is in use.
To fix this, we disable the EXC_BAD_ACCESS handler when installing the
SIGBUS/SIGSEGV handlers, and re-enable them once the compaction is done.
The debugger will still trap on the attempt to read the bad page, but it
will be trapping the SIGBUS signal, rather than the EXC_BAD_ACCESS mach
exception. It's possible to continue from this in the debugger, which
invokes the signal handler and allows forward progress to be made.
This commit makes `rp` report the correct array length in lldb.
When USING_RVARGC is set we use 7 bits of the flags to store the array
len rather than the usual 2, so they need to be part of the mask when
calculating the length in lldb.
When calculating whether rvargc is enabled I've used the same approach
that's used by `GC.using_rvargc?` which is to detect whether there is
more than one size pool in the current objspace.
It previously failed with:
```
1) Failure:
TestThreadInstrumentation#test_thread_instrumentation_fork_safe [/home/runner/work/ruby/ruby/src/test/-ext-/thread/test_instrumentation_api.rb:50]:
<5> expected but was
<4>.
```
Suggesting one `EXIT` event wasn't fired or processed.
Adding an assetion on `Thead#status` may help figure out what is wrong.