| Age | Commit message (Collapse) | Author |
|
SIGABRT is for abnormal termination so we should handle it to output a bug
report. Specifically, glibc malloc uses it to exit when there is corruption.
For example, the following script produces a double free:
mem = Fiddle.malloc(10)
Fiddle.free(mem)
Fiddle.free(mem)
Before this patch, it just outputs the following and exits:
free(): double free detected in tcache 2
After this patch, it also outputs a bug report:
free(): double free detected in tcache 2
test.rb:11: [BUG] Aborted at 0x000003e8000ab65c
|
|
This reverts commit d3b6f835d565ec1590059773fc87589ddf8adc37.
This broke the Docker builds and presumably also 32-bit machines that
don't already have libatomic installed.
|
|
ruby2_keywords on Ruby 2.7+
On Ruby 3.4+, generic argument forwarding is significantly faster
as it does not allocate.
https://github.com/ruby/forwardable/commit/b606c3bf0a
|
|
|
|
https://github.com/ruby/prism/commit/fef2c20777
|
|
Fixes https://github.com/ruby/prism/pull/3740
https://github.com/ruby/prism/commit/464a849184
|
|
Older versions of ASAN do not support vfork. See https://github.com/google/sanitizers/issues/925
|
|
Fixes https://github.com/ruby/prism/pull/3738.
https://github.com/ruby/prism/commit/37bb46ff5f
|
|
They were being parsed as `p((p a, &block) => value)`.
When we get to this point, we must not just have parsed a command call, always consuming the `=>` is not correct.
Closes [Bug #21622]
https://github.com/ruby/prism/commit/796ab0edf4
|
|
[Bug #21703]
RUBY_CRASH_REPORT does not work in some cases when shelling out on Linux.
For example, given the following shell script dump.sh:
#!/usr/bin/env bash
cat > /tmp/crash
And we see it fails like this:
$ RUBY_CRASH_REPORT="|dump.sh" ruby -rfiddle -e "Fiddle::Pointer.new(1, 10)[0]"
cat: -: Resource temporarily unavailable
|
|
`hashFiles` is very unstable on macOS runners.
|
|
|
|
Re-open the exising module by calling `rb_define_module`.
RDoc (`RDoc::Parser::C#do_classes_and_modules`) does not recognize
`rb_path2class` as a class/module definition.
|
|
https://github.com/ruby/date/commit/e41082e068
|
|
|
|
It should check the type of the argument and coercion before
converting the encoding.
|
|
fix a minor misspelling in the documentation comments
|
|
ruby/openssl exposes OIDs to Ruby as strings in many places, but the
conversion logic has been duplicated and the behavior is inconsistent.
There are mainly two patterns:
- Returns the short name associated with the OID/NID, or the dotted
decimal notation if it is unknown to OpenSSL.
- Returns the long name, or the dotted decimal notation.
These patterns are implemented using different OpenSSL APIs and that
caused subtle differences. Add helper functions ossl_asn1obj_to_string()
and ossl_asn1obj_to_string_long_name() to unify the logic.
Also, document the current behaviors where it is not yet done. The
inconsistency was likely unintentional, but since it dates back to the
original implementations, standardizing it now would cause more issues
than it resolves.
https://github.com/ruby/openssl/commit/2ea36c21a4
|
|
obj_to_asn1obj() in ossl_ts.c and ossl_asn1.c are identical. Let's
remove one in ossl_ts.c.
eASN1Error can now be made static to ossl_asn1.c.
https://github.com/ruby/openssl/commit/dcb05c40c2
|
|
curves
EC_GROUP_get_curve_name() returns NID_undef when OpenSSL does not
recognize the curve and there is no associated OID.
Handle this case explicitly and return nil instead of the string
"UNDEF", which should not be exposed outside the extension.
https://github.com/ruby/openssl/commit/2c16821c07
|
|
We can then pass them to the decoder to save having to parse
the string again.
```
== Parsing activitypub.json (58160 bytes)
ruby 3.4.6 (2025-09-16 revision https://github.com/ruby/json/commit/dbd83256b1) +YJIT +PRISM [arm64-darwin24]
Warming up --------------------------------------
after 1.275k i/100ms
Calculating -------------------------------------
after 12.774k (± 0.8%) i/s (78.29 μs/i) - 65.025k in 5.090834s
Comparison:
before: 12314.3 i/s
after: 12773.8 i/s - 1.04x faster
== Parsing twitter.json (567916 bytes)
ruby 3.4.6 (2025-09-16 revision https://github.com/ruby/json/commit/dbd83256b1) +YJIT +PRISM [arm64-darwin24]
Warming up --------------------------------------
after 143.000 i/100ms
Calculating -------------------------------------
after 1.441k (± 0.2%) i/s (693.86 μs/i) - 7.293k in 5.060345s
Comparison:
before: 1430.1 i/s
after: 1441.2 i/s - 1.01x faster
== Parsing citm_catalog.json (1727030 bytes)
ruby 3.4.6 (2025-09-16 revision https://github.com/ruby/json/commit/dbd83256b1) +YJIT +PRISM [arm64-darwin24]
Warming up --------------------------------------
after 69.000 i/100ms
Calculating -------------------------------------
after 695.919 (± 0.4%) i/s (1.44 ms/i) - 3.519k in 5.056691s
Comparison:
before: 687.8 i/s
after: 695.9 i/s - 1.01x faster
```
https://github.com/ruby/json/commit/4f4551f993
|
|
Only `"\/bfnrtu` are valid after a backslash.
https://github.com/ruby/json/commit/f7f8f552ed
|
|
https://github.com/ruby/json/commit/256cad5def
|
|
|
|
|
|
This pattern is extremely common across the ecosystem, I don't think
it's reasonable to deprecate it.
I understand the performance argument, but perhaps the dependency
resolution algorithm can use another method that is private API
and only works with two `Version` instance.
https://github.com/ruby/rubygems/commit/024b4b547a
|
|
|
|
No sense calling a C function.
|
|
|
|
|
|
|
|
This is good for protoboeuf and other binary parsing
|
|
Add `LoadEC` then it's just two `LoadField`.
|
|
|
|
Fix https://github.com/Shopify/ruby/issues/876
|
|
This lets us constant-fold common monomorphic cases.
|
|
Don't emit a CCall.
|
|
On some platoforms, 64bit atomic operations need the dedicated helper
library.
|
|
https://github.com/ruby/json/commit/2a4ebe8250
|
|
https://github.com/ruby/json/commit/305d3832db
|
|
https://github.com/ruby/json/commit/58d60d6b76
|
|
clang-18 has a bug that causes ruby_current_ec to sometimes be null when
using Ractors and crashes like this:
<internal:ractor>:700: [BUG] Segmentation fault at 0x0000000000000030
ruby 4.0.0dev (2025-11-21T06:49:14Z master bcc7b2049c) +PRISM [x86_64-linux]
-- Control frame information -----------------------------------------------
c:0004 p:0003 s:0015 e:000014 l:y b:0001 METHOD <internal:ractor>:700
me:
called_id: receive, type: iseq
owner class: 0x00007ff462dda500 T_CLASS/Ractor::Port
self: 0x00007ff46146d068 ractor/port/Ractor::Port ractor/port
c:0003 p:0008 s:0011 e:000010 l:y b:0001 METHOD <internal:ractor>:311
me:
called_id: receive, type: iseq
owner class: 0x00007ff462ddae60 T_CLASS/(anon)
self: 0x00007ff462ddaf00 T_CLASS/Ractor
c:0002 p:0010 s:0007 e:000006 l:n b:---- BLOCK bootstraptest.test_ractor.rb_2354_1323.rb:9 [FINISH]
self: 0x00007ff46146d090 ractor/Ractor r:68
lvars:
j: T_FIXNUM 66
c:0001 p:---- s:0003 e:000002 l:y b:---- DUMMY [FINISH]
self: T_NIL
-- Ruby level backtrace information ----------------------------------------
bootstraptest.test_ractor.rb_2354_1323.rb:9:in 'block (2 levels) in <main>'
<internal:ractor>:311:in 'receive'
<internal:ractor>:700:in 'receive'
-- Threading information ---------------------------------------------------
Total ractor count: 7
Ruby thread count for this ractor: 1
-- Machine register context ------------------------------------------------
RIP: 0x00007ff47c7df5f0 RBP: 0x000055d77ea5b4f0 RSP: 0x00007ff445fa3af0
RAX: 0x0000000000000000 RBX: 0x000055d77e9fd068 RCX: 0x000055d77e9fd040
RDX: 0x000055d77eb2ac40 RDI: 0x00007ff47cbe7700 RSI: 0x0000000000000000
R8: 0x0000000000000000 R9: 0x0000000000000000 R10: 0x000055d77e9fc830
R11: 0x93ba1054e59bfb14 R12: 0x000055d77ea5b4f0 R13: 0x00007ff445f82f20
R14: 0x00007ff4614cf668 R15: 0x000055d77e9fd040 EFL: 0x0000000000010246
-- C level backtrace information -------------------------------------------
libruby.so.4.0(rb_print_backtrace+0x14) [0x7ff47c8cbd18] vm_dump.c:1105
libruby.so.4.0(rb_vm_bugreport) vm_dump.c:1450
libruby.so.4.0(rb_bug_for_fatal_signal+0x162) [0x7ff47c70ce02] error.c:1131
libruby.so.4.0(sigsegv+0x4a) [0x7ff47c82f20a] signal.c:948
/lib/x86_64-linux-gnu/libc.so.6(0x7ff47c34a330) [0x7ff47c34a330]
libruby.so.4.0(rb_ec_thread_ptr+0x0) [0x7ff47c7df5f0] vm_core.h:2092
libruby.so.4.0(rb_ec_ractor_ptr) vm_core.h:2041
libruby.so.4.0(rb_current_execution_context) vm_core.h:2110
libruby.so.4.0(rb_current_ractor_raw) vm_core.h:2109
libruby.so.4.0(rb_current_ractor) vm_core.h:2117
libruby.so.4.0(ractor_unlock) ractor.c:110
libruby.so.4.0(ractor_unlock_self) ractor.c:125
libruby.so.4.0(ractor_wait) ractor_sync.c:1054
libruby.so.4.0(ractor_wait_receive) ractor_sync.c:1113
libruby.so.4.0(ractor_receive+0x25) [0x7ff47c7ded08] ractor_sync.c:1166
libruby.so.4.0(ractor_port_receive) ractor_sync.c:143
libruby.so.4.0(builtin_inline_class_700) ractor.rb:701
libruby.so.4.0(invoke_bf+0x4) [0x7ff47c8a2060] vm_insnhelper.c:7534
libruby.so.4.0(vm_invoke_builtin_delegate) vm_insnhelper.c:0
libruby.so.4.0(vm_exec_core) insns.def:1674
libruby.so.4.0(vm_exec_loop+0x0) [0x7ff47c89b868] vm.c:2784
libruby.so.4.0(rb_vm_exec) vm.c:2787
libruby.so.4.0(vm_invoke_proc+0x344) [0x7ff47c8b03f4] vm.c:1814
libruby.so.4.0(thread_do_start_proc+0x17a) [0x7ff47c870bba] thread.c:593
libruby.so.4.0(thread_do_start+0x162) [0x7ff47c87042f] thread.c:635
libruby.so.4.0(thread_start_func_2) thread.c:686
libruby.so.4.0(rb_native_mutex_lock+0x0) [0x7ff47c870fd1] thread_pthread.c:2238
libruby.so.4.0(thread_sched_lock_) thread_pthread.c:403
libruby.so.4.0(call_thread_start_func_2) thread_pthread_mn.c:466
libruby.so.4.0(co_start) thread_pthread_mn.c:464
|
|
This was failing on crossruby, likely because HAVE_GCC_ATOMIC_BUILTINS
was true, but HAVE_GCC_ATOMIC_BUILTINS_64 was false. We probably should
have feature detection of 64-bit stdatomics like we do for GCC, but for
now let's keep rbimpl_atomic_u64_fetch_add in sync with load/set.
|
|
Set the `TZ environment variable. `git log` does not recognize UTC
offset in `--before` option, unless full datetime is given.
|
|
`cmd.exe` splits the command line also by equal signs, not only by
space characters.
|
|
https://github.com/ruby/rubygems/commit/fbf6fb667e
|
|
|
|
|
|
(https://github.com/ruby/rubygems/pull/9095)
* Rescue when deleting a non-existent cached gem file
When a gem was in the cache, but another process deletes it first, this
delete command fails.
To work around this, I'm rescuing from Errno::ENOENT and swalling the
error. The file is gone, and we can move on.
* Apply suggestion from @kou
Co-authored-by: Sutou Kouhei <kou@cozmixng.org>
---------
https://github.com/ruby/rubygems/commit/b30bcbc648
Co-authored-by: Hiroshi SHIBATA <hsbt@ruby-lang.org>
Co-authored-by: Sutou Kouhei <kou@cozmixng.org>
|
|
If we use "system" variable in BUNDLE_VERSION on Bundler configuration,
we can use bundler version provided by system installation.
But the current logic returns the first activated version of bundler
like 2.7.2. It makes to confuse users.
https://github.com/ruby/rubygems/commit/4eb66d9549
|