April 2023 - ruby-core - ml.ruby-lang.org

[ruby-core:113160] [Ruby master Bug#19585] Ruby Fails to Build on macOS with --enable-shared and --with-jemalloc
by eviljoel (evil joel) 22 Jul '23

22 Jul '23

Issue #19585 has been reported by eviljoel (evil joel). ---------------------------------------- Bug #19585: Ruby Fails to Build on macOS with --enable-shared and --with-jemalloc https://bugs.ruby-lang.org/issues/19585 * Author: eviljoel (evil joel) * Status: Open * Priority: Normal * ruby -v: 3.2.2, 3.1.3 * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Ruby fails to build on macOS 12.6.4 when configured with --enable-shared and --with-jemalloc. I receive the following linking error: ``` building spec/ruby/optional/capi/ext/bignum_spec.bundle Undefined symbols for architecture x86_64: "_je_free", referenced from: _bignum_spec_rb_big_pack_array in bignum_spec-f7dc36.o "_je_malloc", referenced from: _bignum_spec_rb_big_pack_array in bignum_spec-f7dc36.o ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make: *** [spec/ruby/optional/capi/ext/bignum_spec.bundle] Error 1 ``` It appears that the bignum C API spec requires "-undefined dynamic_lookup" to be enabled. I can get the build to succeed with: ``` ./configure --enable-shared --with-jemalloc DLDFLAGS='-Wl,-undefined,dynamic_lookup' ``` I’ve created several bash scripts to demonstrate that: 1) This is an error with the current production release of Ruby. Running jemallocBug-ruby3.2.2-20230407.sh demonstrates that building Ruby with these parameters fails in Ruby 3.2.2. 2) This is a regression in at least the Ruby 3.1 branch. Running jemallocSucceeds-ruby3.1.2-20230407.sh demonstrates that building Ruby with these parameters worked with Ruby 3.1.2 and running jemallocBug-ruby3.1.3-20230407.sh demonstrates that building Ruby with these parameters fails in Ruby 3.1.3. In the Ruby 3.1 branch, the first commit where this broke appears to be 2244fc9aa7ef8e03ac966e59b581baa021106b46. ld version information: ``` $ ld -v @(#)PROGRAM:ld PROJECT:ld64-820.1 BUILD 20:07:01 Nov 7 2022 configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em LTO support using: LLVM version 14.0.0, (clang-1400.0.29.202) (static support for 29, runtime is 29) TAPI support using: Apple TAPI version 14.0.0 (tapi-1400.0.11) $ ``` clang version information: ``` $ clang -v Apple clang version 14.0.0 (clang-1400.0.29.202) Target: x86_64-apple-darwin21.6.0 Thread model: posix InstalledDir: /Library/Developer/CommandLineTools/usr/bin $ ``` I’m using jemalloc version 5.3.0. MacBook Specs are: ``` Model: MacBook Pro (16-inch, 2019) Processor: 2.4 GHz 8-Core Intel Core i9 Memory: 32 GB 2667 MHz DDR4 Graphics: AMD Radeon Pro 5300M 4 GB and Intel UHD Graphics 630 1536 MB ``` I’ve attached the config.log and config.status for the failed Ruby 3.2.2 build. Please let me know if you need any more information. ---Files-------------------------------- jemallocSucceeds-ruby3.1.2-20230407.sh (804 Bytes) jemallocBug-ruby3.2.2-20230407.sh (804 Bytes) jemallocBug-ruby3.1.3-20230407.sh (804 Bytes) ruby-3.2.2-config.status (34.4 KB) ruby-3.2.2-config.log (1.57 MB) -- https://bugs.ruby-lang.org/

4 3

[ruby-core:112918] [Ruby master Bug#19532] Handling of 6-byte codepoints in left_adjust_char_head in CESU-8 encoding is broken
by Eregon (Benoit Daloze) 22 Jul '23

22 Jul '23

Issue #19532 has been reported by Eregon (Benoit Daloze). ---------------------------------------- Bug #19532: Handling of 6-byte codepoints in left_adjust_char_head in CESU-8 encoding is broken https://bugs.ruby-lang.org/issues/19532 * Author: Eregon (Benoit Daloze) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- Fix in https://github.com/ruby/ruby/pull/7510 -- https://bugs.ruby-lang.org/

4 3

[ruby-core:112926] [Ruby master Misc#19535] Instance variables order is unpredictable on objects with `OBJ_TOO_COMPLEX_SHAPE_ID`
by byroot (Jean Boussier) 22 Jul '23

22 Jul '23

Issue #19535 has been reported by byroot (Jean Boussier). ---------------------------------------- Misc #19535: Instance variables order is unpredictable on objects with `OBJ_TOO_COMPLEX_SHAPE_ID` https://bugs.ruby-lang.org/issues/19535 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal ---------------------------------------- ### Context I've been helping the Mastodon folks in investigating a weird Marshal deserialization bug they randomly experience since they upgraded to Ruby 3.2: https://github.com/mastodon/mastodon/issues/23644 Ultimately the bug comes from a circular dependency issues in the object graph that is serialized when one call `Marshal.dump` on an `ActiveRecord::Base` object. A simplified reproduction to better explain the problem is: ```ruby class Status def normal_order @attributes = { id: 42 } @relations = { self => 1 } self end def inverse_order @relations = nil @attributes = { id: 42 } @relations = { self => 1 } self end def hash @attributes.fetch(:id) end end s = Marshal.load(Marshal.dump(Status.new.normal_order)) s = Marshal.load(Marshal.dump(Status.new.inverse_order)) ``` In short, that `Status` object is both the top level object, and is referenced as a key in a hash, in that same payload. It also defined a custom `#hash` method, that requires some other attribute to be set. It all "works" as long as `@attributes` is dumped before `@relations`. ### Problem The above micro-reproduction uses two different shapes to demonstrate the ordering issues, but in both case the ordering is predictable. However if you generate too many shapes from a single class, it will be marked as `TOO_COMPLEX` and future instance will have their instance variables backed by an `id_table`, which is unordered, and will cause a similar issue. I definitely consider this a bug on the Rails side, and I will do what I can so that Rails doesn't depend on that implicit ordering. However it's unlikely we'll be able to fix older version, and other users may run into this issue when upgrading to Ruby 3.2, so I think it may be worth to try to preserve some sort of predicable ordering, at least for a few more versions. Additionally, debugging it was made particularly difficult, because it would work fine initially, and then break after enough shapes had been generated. Generally speaking I think such semi-predictable behavior is much worse than a fully random behavior (similar to how Go randomize keys order in their maps). ### Historical behavior On Ruby 3.1 and older, the instance variables ordering was defined by the order in which each ivar appeared for the very first time: ```ruby class Foo def set @a = 1 @b = 2 @c = 3 self end def inverse_order @c = 3 @b = 2 @a = 1 self end end p Foo.new.set.instance_variables # => [:@a, :@b, :@c] p Foo.new.inverse_order.instance_variables # => [:@a, :@b, :@c] ``` This means that the order could be different from once execution of the program to another, but would remain stable inside a single process. On 3.2, it's now defined by the order in which each ivar appeared in that specific object instance: ```ruby [:@a, :@b, :@c] [:@c, :@b, :@a] ``` Except, if the object is backed by an `id_table`, in which case it's fully unpredictable. ### Possible changes I discussed this with @tenderlovemaking, and he suggested we could change the `id_table` for an `st_table` so that the ordering could be predictable again, and would behave like objects with a non-complex shape. Another possibility would be to preserve the observable behavior of 3.1 and older. Or of course we could clearly specify that the ordering is random, but if so I think it would be wise to make it always random so that this class of bugs has a much higher chance to be caught early in testing rather than in production. cc @Eregon as I presume this has implications on TruffleRuby as well. -- https://bugs.ruby-lang.org/

5 7

[ruby-core:113380] [Ruby master Bug#19623] Ruby 3.2 MJIT crashes on railsbench
by k0kubun (Takashi Kokubun) 22 Jul '23

22 Jul '23

Issue #19623 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Bug #19623: Ruby 3.2 MJIT crashes on railsbench https://bugs.ruby-lang.org/issues/19623 * Author: k0kubun (Takashi Kokubun) * Status: Closed * Priority: Normal * Backport: 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED ---------------------------------------- Ruby 3.2 MJIT crashes on railsbench when you use `--mjit-max-cache=10000`. ``` [2023-04-29T22:49:00.915217 #412381] FATAL -- : [bc56d52f-5930-4307-8af7-3f58a44eb089] [bc56d52f-5930-4307-8af7-3f58a44eb089] NoMethodError (undefined method `[]' for #<Class:Object>): [bc56d52f-5930-4307-8af7-3f58a44eb089] [bc56d52f-5930-4307-8af7-3f58a44eb089] activesupport (6.0.4) lib/active_support/inflector/inflections.rb:65:in `instance' [bc56d52f-5930-4307-8af7-3f58a44eb089] activesupport (6.0.4) lib/active_support/inflector/inflections.rb:252:in `inflections' [bc56d52f-5930-4307-8af7-3f58a44eb089] activesupport (6.0.4) lib/active_support/inflector/methods.rb:71:in `block in camelize' [bc56d52f-5930-4307-8af7-3f58a44eb089] activesupport (6.0.4) lib/active_support/inflector/methods.rb:71:in `sub' [bc56d52f-5930-4307-8af7-3f58a44eb089] activesupport (6.0.4) lib/active_support/inflector/methods.rb:71:in `camelize' [bc56d52f-5930-4307-8af7-3f58a44eb089] activesupport (6.0.4) lib/active_support/core_ext/string/inflections.rb:94:in `camelize' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/http/request.rb:87:in `controller_class_for' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/http/parameters.rb:100:in `binary_params_for?' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/http/parameters.rb:91:in `set_binary_encoding' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/http/parameters.rb:69:in `path_parameters=' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/journey/router.rb:47:in `block in serve' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/journey/router.rb:32:in `each' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/journey/router.rb:32:in `serve' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/routing/route_set.rb:834:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] rack (2.2.6.3) lib/rack/tempfile_reaper.rb:15:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] rack (2.2.6.3) lib/rack/etag.rb:27:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] rack (2.2.6.3) lib/rack/conditional_get.rb:27:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] rack (2.2.6.3) lib/rack/head.rb:12:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/http/content_security_policy.rb:18:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] rack (2.2.6.3) lib/rack/session/abstract/id.rb:266:in `context' [bc56d52f-5930-4307-8af7-3f58a44eb089] rack (2.2.6.3) lib/rack/session/abstract/id.rb:260:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/middleware/cookies.rb:654:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/middleware/callbacks.rb:27:in `block in call' [bc56d52f-5930-4307-8af7-3f58a44eb089] activesupport (6.0.4) lib/active_support/callbacks.rb:101:in `run_callbacks' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/middleware/callbacks.rb:26:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/middleware/actionable_exceptions.rb:18:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/middleware/debug_exceptions.rb:32:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/middleware/show_exceptions.rb:33:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] railties (6.0.4) lib/rails/rack/logger.rb:37:in `call_app' [bc56d52f-5930-4307-8af7-3f58a44eb089] railties (6.0.4) lib/rails/rack/logger.rb:26:in `block in call' [bc56d52f-5930-4307-8af7-3f58a44eb089] activesupport (6.0.4) lib/active_support/tagged_logging.rb:80:in `block in tagged' [bc56d52f-5930-4307-8af7-3f58a44eb089] activesupport (6.0.4) lib/active_support/tagged_logging.rb:28:in `tagged' [bc56d52f-5930-4307-8af7-3f58a44eb089] activesupport (6.0.4) lib/active_support/tagged_logging.rb:80:in `tagged' [bc56d52f-5930-4307-8af7-3f58a44eb089] railties (6.0.4) lib/rails/rack/logger.rb:26:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/middleware/remote_ip.rb:81:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/middleware/request_id.rb:27:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] rack (2.2.6.3) lib/rack/method_override.rb:24:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] rack (2.2.6.3) lib/rack/runtime.rb:22:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] activesupport (6.0.4) lib/active_support/cache/strategy/local_cache_middleware.rb:29:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/middleware/executor.rb:14:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] rack (2.2.6.3) lib/rack/sendfile.rb:110:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] actionpack (6.0.4) lib/action_dispatch/middleware/host_authorization.rb:76:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] railties (6.0.4) lib/rails/engine.rb:527:in `call' [bc56d52f-5930-4307-8af7-3f58a44eb089] benchmarks/railsbench/benchmark.rb:28:in `block (2 levels) in <main>' [bc56d52f-5930-4307-8af7-3f58a44eb089] benchmarks/railsbench/benchmark.rb:25:in `each' [bc56d52f-5930-4307-8af7-3f58a44eb089] benchmarks/railsbench/benchmark.rb:25:in `block in <main>' [bc56d52f-5930-4307-8af7-3f58a44eb089] /home/k0kubun/src/github.com/Shopify/yjit-bench/harness/harness.rb:29:in `block in run_benchmark' [bc56d52f-5930-4307-8af7-3f58a44eb089] /opt/rubies/mjit/lib/ruby/3.2.0+3/benchmark.rb:311:in `realtime' [bc56d52f-5930-4307-8af7-3f58a44eb089] /home/k0kubun/src/github.com/Shopify/yjit-bench/harness/harness.rb:29:in `run_benchmark' [bc56d52f-5930-4307-8af7-3f58a44eb089] benchmarks/railsbench/benchmark.rb:24:in `<main>' ``` This PR https://github.com/ruby/ruby/pull/7774 fixes the problem. This ticket is to request a backport for Ruby 3.2. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:113382] [Ruby master Bug#19625] Ruby 3.2 MJIT never triggers JIT compaction
by k0kubun (Takashi Kokubun) 22 Jul '23

22 Jul '23

Issue #19625 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Bug #19625: Ruby 3.2 MJIT never triggers JIT compaction https://bugs.ruby-lang.org/issues/19625 * Author: k0kubun (Takashi Kokubun) * Status: Closed * Priority: Normal * Backport: 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED ---------------------------------------- [This patch](https://github.com/ruby/ruby/pull/6900) accidentally removed a condition to trigger JIT compaction from Ruby 3.2. This PR https://github.com/ruby/ruby/pull/7777 makes it work again. This ticket is to request a backport for Ruby 3.2. -- https://bugs.ruby-lang.org/

2 1

[ruby-core:112906] [Ruby master Bug#19531] ObjectSpace::WeakMap: replaced values still clear the key they were assigned to
by byroot (Jean Boussier) 22 Jul '23

22 Jul '23

Issue #19531 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #19531: ObjectSpace::WeakMap: replaced values still clear the key they were assigned to https://bugs.ruby-lang.org/issues/19531 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * Backport: 2.7: WONTFIX, 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- ### Reproduction script ```ruby wmap = ObjectSpace::WeakMap.new a = "A" b = "B" wmap[1] = a wmap[1] = b # the table entry with 1 is still in the list of entries to clear when `a` is GCed a = nil GC.start p wmap[1] # Should be `"B"`, but is `nil` ``` ### Explanation What happens is that when we set `wmap[1] = "A"`, WeakMap internally keeps a list of keys to clear when `"A"` is GCed, e.g. pseudo code: ```ruby class WeakMap def []=(key, value) @hash[key] = value @reverse[value] << key end end ``` But it doesn't clear previously kept mapping when a key is overwritten. I'll work on a fix. ### References https://github.com/protocolbuffers/protobuf/pull/12216 -- https://bugs.ruby-lang.org/

2 2

[ruby-core:111873] [Ruby master Bug#19351] Promote bundled gems at Ruby 3.3
by hsbt (Hiroshi SHIBATA) 19 Jul '23

19 Jul '23

Issue #19351 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Bug #19351: Promote bundled gems at Ruby 3.3 https://bugs.ruby-lang.org/issues/19351 * Author: hsbt (Hiroshi SHIBATA) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- In Ruby 3.2, the default gems and bundled gems are changed only adding `syntax_suggest`. I and some committers are considering promote default gems to bundled gems again for Ruby 3.3+. We hope to keep the current developer experience with dependency resolution and ignore the additional work like "Put gem "xxx" into your Gemfile" for developers. ### Proposal We propose the following libraries will promote default gems to bundled gems at Ruby 3.3. They are not the dependencies of Rails and RubyGems/Bundler. ``` abbrev getoptlong optparse observable resolv resolv-replace rinda un fcntl nkf syslog win32ole ``` ### Additional works I also propose to poromote rails dependencies: ``` ostruct base64 irb rdoc tsort singleton delegate ``` and gems maintained by @kou ``` csv strscan fiddle stringio ``` But if we promote them to bundled gems, many of users need to add `gem "csv"` into their Gemfile. I'm considering to avoid this situation. Can we the specific feature of bundled gems to RubyGems or Bundler? Example, bundler have allowed list for bundled gems. So, listed gems could be require without Gemfile under the bundle exec. -- https://bugs.ruby-lang.org/

6 25

[ruby-core:113109] [Ruby master Bug#19577] Backport commit 537183cd2ac0163851277b46a2f21ea5914c11c0
by peterzhu2118 (Peter Zhu) 18 Jul '23

18 Jul '23

Issue #19577 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #19577: Backport commit 537183cd2ac0163851277b46a2f21ea5914c11c0 https://bugs.ruby-lang.org/issues/19577 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal * Backport: 3.0: DONTNEED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- Please backport commit [537183cd2ac0163851277b46a2f21ea5914c11c0](https://github.com/ruby/ruby/comm…. We've seen this crash in our production systems. -- https://bugs.ruby-lang.org/

3 2

[ruby-core:113129] [Ruby master Bug#19580] Ensure ruby_xfree won't segfault if called after ruby_vm_destruct
by mdalessio (Mike Dalessio) 18 Jul '23

18 Jul '23

Issue #19580 has been reported by mdalessio (Mike Dalessio). ---------------------------------------- Bug #19580: Ensure ruby_xfree won't segfault if called after ruby_vm_destruct https://bugs.ruby-lang.org/issues/19580 * Author: mdalessio (Mike Dalessio) * Status: Open * Priority: Normal * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- Github PR: https://github.com/ruby/ruby/pull/7663 The POSIX Threads API provides the ability to define a destructor to clean up thread-local storage at thread exit by using `pthread_key_create` to bind a storage key and an associated destructor function, and `pthread_setspecific` to associate a value with that key. If a C extension is using `ruby_xmalloc` and `ruby_xfree` to manage memory, then the destructor function will likely call `ruby_xfree`. There is a small window of time as a process is exiting -- after `ruby_vm_destruct` but before the process exits -- in which a thread may exit and the destructor function called, leading to a segfault. ### Real-world use case The real-world scenario motivating this change is libxml2's pthread code which uses `pthread_key_create` to set up a destructor that is called at thread exit to clean up thread-local storage associated with the thread by `pthread_setspecific`. Nokogiri has, since 2009, configured libxml2 to use `ruby_xmalloc` and `ruby_xfree` so that Ruby's memory management is aware of the allocated memory. As a result, `ruby_xfree` is being called by the pthread destructor, which may lead to a segfault that looks like: [BUG] Segmentation fault at 0x0000000000000420 ruby 3.3.0dev (2023-03-19T06:13:25Z master ca9355e173) [x86_64-linux] -- Machine register context ------------------------------------------------ RIP: 0x00007f9b6311124e RBP: 0x00007f9b58001530 RSP: 0x00007f9b5d8eed60 RAX: 0x0000000000000000 RBX: 0x00007f9b58001888 RCX: 0x00000000000003ff RDX: 0x00007f9b5dad62b0 RDI: 0x00007f9b58007090 RSI: 0x0000000000000000 R8: 0x00007f9b5d8eed64 R9: 0x00000000000000ca R10: 0x0000000000000000 R11: 0x0000000000000246 R12: 0x00007f9b58007090 R13: 0x00007f9b62e1bae8 R14: 0x0000000000000004 R15: 0x00007f9b5d8efb58 EFL: 0x0000000000010206 -- C level backtrace information ------------------------------------------- .../3.3.0-dev/lib/libruby.so.3.3(rb_print_backtrace+0xd) [0x7f9b632e6f1f] /home/flavorjones/code/oss/ruby/vm_dump.c:785 .../3.3.0-dev/lib/libruby.so.3.3(rb_vm_bugreport) /home/flavorjones/code/oss/ruby/vm_dump.c:1101 .../3.3.0-dev/lib/libruby.so.3.3(rb_bug_for_fatal_signal+0xf4) [0x7f9b630eead4] /home/flavorjones/code/oss/ruby/error.c:813 .../3.3.0-dev/lib/libruby.so.3.3(sigsegv+0x4d) [0x7f9b63233bbd] /home/flavorjones/code/oss/ruby/signal.c:964 /lib/x86_64-linux-gnu/libc.so.6(0x7f9b62c42520) [0x7f9b62c42520] .../3.3.0-dev/lib/libruby.so.3.3(ruby_sized_xfree+0x3) [0x7f9b6311124e] /home/flavorjones/code/oss/ruby/gc.c:12666 .../3.3.0-dev/lib/libruby.so.3.3(ruby_sized_xfree) /home/flavorjones/code/oss/ruby/gc.c:12663 .../lib/nokogiri/nokogiri.so(xmlResetError+0x0) [0x7f9b5da6ab4a] .../tmp/x86_64-linux/nokogiri/3.0.5/tmp/x86_64-pc-linux-gnu/ports/libxml2/2.10.3/libxml2-2.10.3/error.c:880 .../lib/nokogiri/nokogiri.so(xmlResetError) .../tmp/x86_64-linux/nokogiri/3.0.5/tmp/x86_64-pc-linux-gnu/ports/libxml2/2.10.3/libxml2-2.10.3/error.c:873 .../lib/nokogiri/nokogiri.so(xmlResetError) (null):0 .../lib/nokogiri/nokogiri.so(xmlFreeGlobalState+0x14) [0x7f9b5dad62c4] .../tmp/x86_64-linux/nokogiri/3.0.5/tmp/x86_64-pc-linux-gnu/ports/libxml2/2.10.3/libxml2-2.10.3/threads.c:548 /lib/x86_64-linux-gnu/libc.so.6(__nptl_deallocate_tsd+0x77) [0x7f9b62c91711] ./nptl/nptl_deallocate_tsd.c:73 /lib/x86_64-linux-gnu/libc.so.6(__nptl_deallocate_tsd) ./nptl/nptl_deallocate_tsd.c:22 /lib/x86_64-linux-gnu/libc.so.6(start_thread+0x17a) [0x7f9b62c949ca] ./nptl/pthread_create.c:453 [0x7f9b62d26a00] I've reproduced this in Ruby 3.0, 3.1, 3.2, and master by using the following ruby code: # must have an error in it to cause pthread_setspecific to be called html = "<div foo='asdf>asdf</div>" Thread.new { Nokogiri::HTML4::Document.parse(html) } sleep 3 # THREAD_CACHE_TIME exit 0 The timing is admittedly hard to reproduce, but [Gitlab has seen this in their CI pipelines a few dozen times](https://gitlab.com/gitlab-org/gitlab/-/issues/390313) and it's made easier if the process lifetime is extended by an `atexit`-registered function. -- https://bugs.ruby-lang.org/

4 4

[ruby-core:113198] [Ruby master Bug#19593] Crash due to throw data set as cause
by peterzhu2118 (Peter Zhu) 18 Jul '23

18 Jul '23

Issue #19593 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #19593: Crash due to throw data set as cause https://bugs.ruby-lang.org/issues/19593 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Priority: Normal * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- GitHub PR: https://github.com/ruby/ruby/pull/7696 rb_ec_setup_exception did not check if errinfo is a throw_data. This can cause crashes in code since it is assumed that id_cause is an object. We saw a crash in show_cause due to id_cause of errinfo being a throw_data. It crashes on rb_obj_is_kind_of since it cannot be called on T_IMEMO objects. Unfortunately, we couldn't find a reproduction script, however we debugged the core dump and rb_ec_setup_exception is the only place where id_cause is assigned from errinfo without checking if it is a throw_data. ``` 0x0000556c5708e6dd in sigsegv (sig=11, info=0x7f301befa3f0, ctx=0x7f301befa2c0) at signal.c:964 0x00007f301d046420 in <signal handler called> () at /lib/x86_64-linux-gnu/libpthread.so.0 class_search_class_ancestor (c=139844586301760, cl=<optimized out>) at object.c:810 rb_obj_is_kind_of (obj=obj@entry=139839221734880, c=139844586301760) at object.c:861 0x0000556c56f2f00f in show_cause (errinfo=errinfo@entry=139838840645160, str=str@entry=139839221730520, opt=139839221730480, highlight=0, reverse=reverse@entry=0, backtrace_limit=backtrace_limit@entry=-1, shown_causes=0x7ffe9d1a2d68) at ./include/ruby/internal/special_consts.h:175 ``` -- https://bugs.ruby-lang.org/

3 2