[ruby/zlib] [Bug #18358] Fix crash in zlib when in progress
When Zlib::Inflate#inflate or Zlib::Deflate#deflate is called
recursively inside the block, a crash can occur because of an
use-after-free bug.
https://github.com/ruby/zlib/commit/50fb8a0338
---
ext/zlib/zlib.c | 117 ++++++++++++++++++++++++++++++++-----------------
test/zlib/test_zlib.rb | 10 ++++-
2 files changed, 85 insertions(+), 42 deletions(-)
[ruby/zlib] Synchronize access to zstream to prevent segfault in
multithreaded use
I'm not sure whether this handles all multithreaded use cases,
but this handles the example that crashes almost immediately
and does 10,000,000 total deflates using 100 separate threads.
To prevent the tests from taking forever, the committed test
for this uses only 10,000 deflates across 10 separate threads,
which still causes a segfault in the previous implementation
almost immediately.
Fixes [Bug #17803]
https://github.com/ruby/zlib/commit/4b1023b3f2
---
ext/zlib/zlib.c | 33 ++++++++++++++++++++++++++-
test/zlib/test_zlib.rb | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 93 insertions(+), 1 deletion(-)
Use valid `ec` for postponed job.
Postponed job can be registered from non-Ruby thread, which means
`ec` in TLS can be NULL. In this case, use main thread's `ec` instead.
See https://github.com/ruby/ruby/pull/4108
and https://github.com/ruby/ruby/pull/4336
---
vm_trace.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
Avoid assert failure when NULL EC is expected
After 5680c38c75, postponed job APIs now
expect to be called on native threads not managed by Ruby and handles
getting a NULL execution context. However, in debug builds the change
runs into an assertion failure with GET_EC() which asserts that EC is
non-NULL. Avoid the assertion failure by passing `false` for `expect_ec`
instead as the intention is to handle when there is no EC.
Add a test from John Crepezzi and John Hawthorn to exercise this
situation.
See GH-4108
See GH-5094
[Bug #17573]
Co-authored-by: John Hawthorn <john@hawthorn.email>
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
---
ext/-test-/postponed_job/postponed_job.c | 31 ++++++++++++++++++++++++++
test/-ext-/postponed_job/test_postponed_job.rb | 7 ++++++
vm_trace.c | 2 +-
3 files changed, 39 insertions(+), 1 deletion(-)
Bring the local copy of ruby/openssl in sync with the upstream gem
release v2.2.1. The commits happened in the upstream repository can be
found at:
https://github.com/ruby/openssl/compare/v2.2.0...v2.2.1
Note that many of these have already been applied to ruby.git and don't
appear in the file changes of this commit.
undefine alloc functions for C extensions
per guidance in doc/extension.rdoc, these classes now undefine their
alloc functions:
- ObjectSpace::InternalObjectWrapper
- Socket::Ifaddr
---
ext/objspace/objspace.c | 1 +
ext/socket/ifaddr.c | 1 +
2 files changed, 2 insertions(+)
Guard array when appending
This prevents early collection of the array. The GC doesn't see the
array on the stack when Ruby is compiled with optimizations enabled
[ruby-core:105099] [Bug #18140]
---
array.c | 1 +
test/ruby/test_array.rb | 6 ++++++
2 files changed, 7 insertions(+)
Guard array when appending
This prevents early collection of the array. The GC doesn't see the
array on the stack when Ruby is compiled with optimizations enabled
Thanks @jhaberman for the test case
[ruby-core:105099] [Bug #18140]
---
ext/-test-/array/concat/depend | 321 ++++++++++++++++++++++++++++++++
ext/-test-/array/concat/extconf.rb | 2 +
ext/-test-/array/concat/to_ary_conact.c | 64 +++++++
test/-ext-/array/test_to_ary_concat.rb | 20 ++
4 files changed, 407 insertions(+)
create mode 100644 ext/-test-/array/concat/depend
create mode 100644 ext/-test-/array/concat/extconf.rb
create mode 100644 ext/-test-/array/concat/to_ary_conact.c
create mode 100644 test/-ext-/array/test_to_ary_concat.rb
Refined test [Bug #18140]
---
ext/-test-/array/concat/to_ary_conact.c | 48 +++++++--------------------------
test/ruby/test_array.rb | 5 +++-
2 files changed, 13 insertions(+), 40 deletions(-)
Scan the coderange in the given encoding
---
ext/-test-/string/enc_str_buf_cat.c | 14 ++++++++++++++
string.c | 32 ++++++++++++++++++++++---------
test/-ext-/string/test_enc_str_buf_cat.rb | 9 +++++++++
3 files changed, 46 insertions(+), 9 deletions(-)
Work around issue transcoding issue with non-ASCII compatible
encodings and xml escaping
When using a non-ASCII compatible source and destination encoding
and xml escaping (the :xml option to String#encode), the resulting
string was broken, as it used the correct non-ASCII compatible
encoding, but contained data that was ASCII-compatible instead of
compatible with the string's encoding.
Work around this issue by detecting the case where both the
source and destination encoding are non-ASCII compatible, and
transcoding the source string from the non-ASCII compatible
encoding to UTF-8. The xml escaping code will correctly handle
the UTF-8 source string and the return the correctly encoded
and escaped value.
Fixes [Bug #12052]
Co-authored-by: Nobuyoshi Nakada <nobu@ruby-lang.org>
---
test/ruby/test_transcode.rb | 19 +++++++++++++++++++
transcode.c | 6 ++++++
2 files changed, 25 insertions(+)
=?UTF-8?q?-=20add=20regression=20tests=20for=20U+6E7F=20(?=
=?UTF-8?q?=E6=B9=BF)=20in=20ISO-2022-JP?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
In ISO-2022-JP, the bytes use to code are the same as those for "<>".
This adds regression tests to make sure that these bytes, when representing
湿, are NOT escaped with encode("ISO-2022-JP, xml: :text) or similar.
These are additional regression tests for #12052.
---
test/ruby/test_transcode.rb | 3 +++
1 file changed, 3 insertions(+)
constant cache `IC` is accessed by non-atomic manner and there are
thread-safety issues, so Ruby 3.0 disables to use const cache on
non-main ractors.
This patch enables it by introducing `imemo_constcache` and allocates
it by every re-fill of const cache like `imemo_callcache`.
[Bug #17510]
Now `IC` only has one entry `IC::entry` and it points to
`iseq_inline_constant_cache_entry`, managed by T_IMEMO object.
`IC` is atomic data structure so `rb_mjit_before_vm_ic_update()` and
`rb_mjit_after_vm_ic_update()` is not needed.
Hiroshi SHIBATA