Skip to content

Fix for r41109#6

Merged
nurse merged 1 commit into
ruby:rubyfrom
mrkn:fix_for_r41109
Jun 7, 2013
Merged

Fix for r41109#6
nurse merged 1 commit into
ruby:rubyfrom
mrkn:fix_for_r41109

Conversation

@mrkn

@mrkn mrkn commented Jun 7, 2013

Copy link
Copy Markdown
Member

Fix spec for Numeric#quo to follow cruby's r41109.

nurse added a commit that referenced this pull request Jun 7, 2013
@nurse nurse merged commit e71968b into ruby:ruby Jun 7, 2013
koic added a commit to koic/spec that referenced this pull request Jul 10, 2026
The spec added in 20ae94d passed a pointer to a 4-byte C stack struct
as both the `obj` and `arg` arguments of rb_exec_recursive(). While `arg`
is passed through to the callback as-is, `obj` is used as a key of the
recursion guard hash in CRuby. Storing it there fires the GC write
barrier, which reads the (8-byte) object flags from the non-object
address, and AddressSanitizer reports a stack-buffer-overflow:

    ==29649==ERROR: AddressSanitizer: stack-buffer-overflow ...
    READ of size 8 at 0x7f0d9b7c7b20 thread T0
        #0 RB_BUILTIN_TYPE include/ruby/internal/value_type.h:191:30
        ruby#1 rb_gc_impl_writebarrier gc/default/default.c:6621:5
        ...
        ruby#6 exec_recursive thread.c:5602:13
        ruby#7 kernel_spec_rb_exec_recursive_with_pointer
           spec/ruby/optional/capi/ext/kernel_spec.c:370:10

This crash has been blocking the daily `ruby-head` releases of
ruby/ruby-dev-builder (`build (ubuntu-24.04, asan)`) since 2026-07-08:
https://github.com/ruby/ruby-dev-builder/actions/runs/29044853326

As a result, downstream CIs that use `ruby-head` via ruby/setup-ruby are
stuck with the 2026-07-06 snapshot, which predates ruby/ruby@291d0d95ea
("onig_reg_copy_body: fix copying of exact_end"). This is how the
problem was found: the "Spec - ubuntu head" job on the default branch of
rubocop/rubocop keeps failing because `Regexp.new(regexp)` copies made
for the `AllowedPatterns` config silently fail to match on that
snapshot:
https://github.com/rubocop/rubocop/actions/runs/29061954887/job/86265559997

The intent of the spec is that the callback argument is passed as-is,
so keep the raw pointer for `arg` and use a real Ruby object as the
recursion key.
koic added a commit to koic/spec that referenced this pull request Jul 10, 2026
The spec added in 20ae94d passed a pointer to a 4-byte C stack struct as both the `obj`
and `arg` arguments of rb_exec_recursive(). While `arg` is passed through to the callback as-is,
`obj` is used as a key of the recursion guard hash in CRuby. Storing it there fires the GC write barrier,
which reads the (8-byte) object flags from the non-object address, and AddressSanitizer reports a stack-buffer-overflow:

```
    ==29649==ERROR: AddressSanitizer: stack-buffer-overflow ...
    READ of size 8 at 0x7f0d9b7c7b20 thread T0
        #0 RB_BUILTIN_TYPE include/ruby/internal/value_type.h:191:30
        ruby#1 rb_gc_impl_writebarrier gc/default/default.c:6621:5
        ...
        ruby#6 exec_recursive thread.c:5602:13
        ruby#7 kernel_spec_rb_exec_recursive_with_pointer
           spec/ruby/optional/capi/ext/kernel_spec.c:370:10
```

This crash has been blocking the daily `ruby-head` releases of ruby/ruby-dev-builder (`build (ubuntu-24.04, asan)`)
since 2026-07-08:
https://github.com/ruby/ruby-dev-builder/actions/runs/29044853326

As a result, downstream CIs that use `ruby-head` via ruby/setup-ruby are stuck with the 2026-07-06 snapshot,
which predates ruby/ruby@291d0d95ea ("onig_reg_copy_body: fix copying of exact_end"). This is how the problem was found:
the "Spec - ubuntu head" job on the default branch of rubocop/rubocop keeps failing because `Regexp.new(regexp)` copies made
for the `AllowedPatterns` config silently fail to match on that snapshot:
https://github.com/rubocop/rubocop/actions/runs/29061954887/job/86265559997

The intent of the spec is that the callback argument is passed as-is, so keep the raw pointer for `arg` and
use a real Ruby object as the recursion key.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants