June 2025 - ruby-core - ml.ruby-lang.org

[ruby-core:122489] [Ruby Bug#17617] When a Ractor's incoming port is closed, Ractor.receive_if does not raise Ractor::ClosedError, but instead blocks indefinitely
by jhawthorn (John Hawthorn) 06 Jun '25

06 Jun '25

Issue #17617 has been updated by jhawthorn (John Hawthorn). Status changed from Assigned to Closed `receive_if` has been removed with the introduction of `Ractor::Port`, so this should no longer be an issue ---------------------------------------- Bug #17617: When a Ractor's incoming port is closed, Ractor.receive_if does not raise Ractor::ClosedError, but instead blocks indefinitely https://bugs.ruby-lang.org/issues/17617#change-113678 * Author: dazuma (Daniel Azuma) * Status: Closed * Assignee: ractor * ruby -v: ruby 3.3.0dev (2023-11-13T21:00:10Z master e8ab3f7010) [x86_64-darwin23] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- If Ractor#close_incoming is called on a Ractor, any pending Ractor.receive call will raise Ractor::ClosedError. However, any pending Ractor.receive_if call will not; instead, it never returns. ``` r1 = Ractor.new do Ractor.receive rescue => e e end r1.close_incoming result = r1.take puts "**** taken: #{result}" # displays the Ractor::ClosedError r2 = Ractor.new do Ractor.receive_if { true } puts "**** never reaches here" rescue => e puts "**** never reaches here" e end r2.close_incoming puts "**** hangs here..." r2.take puts "**** never reaches here" ``` This was tested against both 3.0.0 and 3.1.0 head, with the same result. ``` % ruby -v ruby 3.1.0dev (2021-02-09T13:22:37Z master e7a831de8e) [x86_64-darwin20] ``` ``` % ruby -v ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20 ``` I have also tried including sleep statements to force the Ractor.receive_if to execute both before and after the Ractor#close_incoming call. The result is the same either way. receive_if hangs regardless of whether the incoming port is already closed when receive_if is invoked, or whether the port is closed while the receive_if is already blocking. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:121182] [Ruby master Bug#21158] Ractor using 'receive_if' sits in busy wait when there are skipped messages in the incoming queue
by NeilW (Neil Wilson) 06 Jun '25

06 Jun '25

Issue #21158 has been reported by NeilW (Neil Wilson). ---------------------------------------- Bug #21158: Ractor using 'receive_if' sits in busy wait when there are skipped messages in the incoming queue https://bugs.ruby-lang.org/issues/21158 * Author: NeilW (Neil Wilson) * Status: Open * ruby -v: ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- When using the conditional receive example from the Ractor documentation (either as a script, or within irb) <pre> r = Ractor.new do val = Ractor.receive_if{|msg| msg.is_a?(Array)} puts "Received successfully: #{val}" end r.send(1) r.send('test') </pre> ruby will sit in busy wait, pegging the processor at 100%, until it gets a message that matches the condition. Within irb it will often stop the REPL responding. The same problem occurs on ruby 3.02, 3.3.7 and 3.4.1 -- https://bugs.ruby-lang.org/

3 2

[ruby-core:122265] [Ruby Misc#21369] Propose Max Bernstein (@tekknolagi) as a core committer
by k0kubun (Takashi Kokubun) 06 Jun '25

06 Jun '25

Issue #21369 has been reported by k0kubun (Takashi Kokubun). ---------------------------------------- Misc #21369: Propose Max Bernstein (@tekknolagi) as a core committer https://bugs.ruby-lang.org/issues/21369 * Author: k0kubun (Takashi Kokubun) * Status: Open ---------------------------------------- ## Proposal I'd like to propose Max Bernstein (@tekknolagi) as a committer. He has a strong background in compilers, having previously worked on CPython/Cinder at Meta, and has demonstrated leadership in designing and optimizing ZJIT. Given that he is leading the development of the ZJIT IR and has been making a lot of contributions, I believe he should be empowered to merge such changes himself. I'll include his message below for reference: ## Max Bernstein's Message I have been working on Ruby since December 2024. My main contributions so far have been to ZJIT: * The high-level IR (HIR) data structures * The IR * The type lattice https://github.com/Shopify/zjit/pull/19 * Transforming YARV bytecode into HIR * Optimization on HIR, such as * Type inference https://github.com/Shopify/zjit/pull/23 * Constant folding https://github.com/Shopify/zjit/pull/74 * Direct calls https://github.com/Shopify/zjit/pull/84 * Strength reduction * Dead code elimination (DCE) https://github.com/Shopify/zjit/pull/89 After we moved the ZJIT repo into ruby/ruby, I have continued contributing (see [all PRs](https://github.com/ruby/ruby/pulls?q=author%3Atekknolagi)) I would like to continue contributing to ZJIT and eventually to other parts of Ruby too. Being a maintainer would make it easier to work on ZJIT, especially as we continue the project bringup phase. -- https://bugs.ruby-lang.org/

7 7

[ruby-core:121443] [Ruby Bug#21198] Fiber::Scheduler#blocking_operation_wait crash due to stack-use-after-return
by peterzhu2118 (Peter Zhu) 06 Jun '25

06 Jun '25

Issue #21198 has been reported by peterzhu2118 (Peter Zhu). ---------------------------------------- Bug #21198: Fiber::Scheduler#blocking_operation_wait crash due to stack-use-after-return https://bugs.ruby-lang.org/issues/21198 * Author: peterzhu2118 (Peter Zhu) * Status: Open * Backport: 3.1: DONTNEED, 3.2: DONTNEED, 3.3: DONTNEED, 3.4: REQUIRED ---------------------------------------- The Fiber::Scheduler#blocking_operation_wait method is passed a proc through the `rb_fiber_scheduler_blocking_operation_wait` function. This function stack allocates the arguments used for the proc ([source](https://github.com/ruby/ruby/blob/2183899fd184ab1cfee80d57c0dd6f4dc…) If this proc is captured anywhere, then calling it again will illegally read from and write to stack space. The following script demonstrates this issue using the [test/fiber/scheduler.rb](https://github.com/ruby/ruby/blob/master/test/fibe… scheduler: ```ruby require_relative "test/fiber/scheduler" class MyScheduler < Scheduler def blocking_operation_wait(work) super $work = work end end scheduler = MyScheduler.new Fiber.set_scheduler(scheduler) require "tempfile" Fiber.schedule do file = Tempfile.new file.write("hello world!") $work.call end scheduler.run ``` Crashes with: ``` test.rb:19: [BUG] Bus Error at 0xce0f57696add0045 ruby 3.4.2 (2025-02-15 revision d2930f8e7a) +PRISM [arm64-darwin24] -- Crash Report log information -------------------------------------------- See Crash Report log file in one of the following locations: * ~/Library/Logs/DiagnosticReports * /Library/Logs/DiagnosticReports for more details. Don't forget to include the above Crash Report log file in bug reports. -- Control frame information ----------------------------------------------- c:0003 p:---- s:0010 e:000009 IFUNC c:0002 p:0017 s:0007 e:000006 BLOCK test.rb:19 [FINISH] c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- test.rb:19:in 'block in <main>' -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 Note that the Fiber scheduler is enabled -- Machine register context ------------------------------------------------ x0: 0x000000010063a5f0 x1: 0x000000014b80ce00 x2: 0x0000000000000000 x3: 0x000000014b60f060 x4: 0x0000000000000000 x5: 0x0000000000000000 x6: 0x0000000000000004 x7: 0x0000000000000000 x18: 0x0000000000000000 x19: 0x000000014b6a4840 x20: 0xce0f57696add0045 x21: 0x000000010063a5f0 x22: 0x000000014b60f060 x23: 0x0000000000000000 x24: 0x000000014b60f998 x25: 0x0000000000014273 x26: 0x000000014b60f060 x27: 0x000000014b60f060 x28: 0x000000014b80ce00 lr: 0x0000000100d881d8 fp: 0x000000011bb039f0 sp: 0x000000011bb03980 -- C level backtrace information ------------------------------------------- SEGV received in BUS handler [1] 52599 abort ruby test.rb ``` -- https://bugs.ruby-lang.org/

2 3

[ruby-core:121861] [Ruby Bug#21312] ruby 3.5-dev installs a gemspec for rdoc that misses dependencies
by deivid 06 Jun '25

06 Jun '25

Issue #21312 has been reported by deivid (David Rodríguez). ---------------------------------------- Bug #21312: ruby 3.5-dev installs a gemspec for rdoc that misses dependencies https://bugs.ruby-lang.org/issues/21312 * Author: deivid (David Rodríguez) * Status: Open * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Similarly to https://bugs.ruby-lang.org/issues/20581, installing ruby 3.5-dev installs a gemspec for rdoc that it's missing its own dependency on psych. This causes issues when using Bundler, as reported at https://github.com/rubygems/rubygems/issues/8637. I created a workaround in Bundler to behave better under this situation and print a warning rather than creating an incorrect lockfile, but ruby installer should fix this too. Thank you! -- https://bugs.ruby-lang.org/

2 2

[ruby-core:121601] [Ruby Feature#21258] Retire CGI library from Ruby 3.5
by hsbt (Hiroshi SHIBATA) 06 Jun '25

06 Jun '25

Issue #21258 has been reported by hsbt (Hiroshi SHIBATA). ---------------------------------------- Feature #21258: Retire CGI library from Ruby 3.5 https://bugs.ruby-lang.org/issues/21258 * Author: hsbt (Hiroshi SHIBATA) * Status: Open ---------------------------------------- I would like to retire CGI library from Ruby 3.5.0 release. It means CGI is not promoted bundled gems. The users need to run `gem install cgi` after Ruby 3.5 if they want to use CGI library. ## Background I handled two CVEs related CGI library at https://www.ruby-lang.org/en/news/2025/02/26/security-advisories/ We shouldn't spend our time to maintain CGI library in the future because CGI is old protocol. In fact, Perl 5.22.0 removed CGI.pm at 2015, Python 3.13 also removed cgi at Nov 2024. ## Problem CGI is not using widely today. But `cgi/escape` is core feature in Ruby ecosystem. `erb`, `net-http` and `bundler` depend `CGI.escape`/`CGI.unescape`. And `CGI.escapeHTML`, `CGI.escapeURIComponent` are used at that libraries. ## Solution 1. We keep only `cgi/escape` feature in Ruby. The current CGI library is removed and depend `cgi-escape` gem. 2. We migrate `cgi/escape` to other class/module. The current CGI library and `cgi/escape` are removed. The new class/module location is diffcult. I discussed that with some Ruby core member. * `URI.escape/unescape`: `URI.escape` is migrated to `URI::RFC2396_PARSER.escape` at Ruby 3.4. The new `URI.escape` is confusing name with historical reason. * `URI::Util.escape`: It seems okay...? I think URI or related name are good place for that because other language provide that under the url libraries: Python: ``` import urllib.parse urllib.parse.quote() ``` Java: ``` import java.net.URLEncoder; URLEncoder.encode() ``` Go: ``` import "net/url" url.QueryEscape() ``` ## Migration plan If Idea 2 is accepted and decide new location, We provide dummy module and method for `cgi/escape`. That dummy module call new method and warn about deprecating `cgi/escape`. -- https://bugs.ruby-lang.org/

8 10

[ruby-core:122414] [Ruby Bug#21397] `snap run ruby.gem` fails when both snap and deb package are installed
by mk76835897 (Max Kapur) 06 Jun '25

06 Jun '25

Issue #21397 has been reported by mk76835897 (Max Kapur). ---------------------------------------- Bug #21397: `snap run ruby.gem` fails when both snap and deb package are installed https://bugs.ruby-lang.org/issues/21397 * Author: mk76835897 (Max Kapur) * Status: Open * ruby -v: ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [x86_64-linux] * Backport: 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- There appears to be a packaging issue with the [official](https://www.ruby-lang.org/en/news/2018/11/08/snap/) Ruby snap. On a clean virtual machine running Ubuntu 24.04, the `gem` command fails when run from the snap if the Ruby deb package is also present: ``` $ sudo apt update -y $ sudo apt upgrade -y $ sudo apt install ruby-full -y $ sudo snap install --classic ruby $ snap run ruby.gem -v ruby: symbol lookup error: /snap/core20/current/lib/x86_64-linux-gnu/libpthread.so.0: undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE ``` The error does not occur unless the deb package is installed. However, installing the snap alongside the deb is not unusual, as many Ubuntu images (such as the GitHub Actions runners) have Ruby v3.3 preinstalled as a deb by default. Installing the snap is an easy way to get Ruby v3.4 (without compiling it from source). Additional info: ``` $ snap version snap 2.68.4 snapd 2.68.4 series 16 ubuntu 24.04 kernel 6.8.0-45-generic $ ruby -v ruby 3.2.3 (2024-01-18 revision 52bb2ac0a6) [x86_64-linux-gnu] $ snap run ruby -v ruby 3.4.4 (2025-05-14 revision a38531fd3f) +PRISM [x86_64-linux] ``` - I previously reported this bug on GitHub: https://github.com/ruby/snap.ruby/issues/42 - I also consulted the Snapcraft page, but it just says to report bugs to info(a)ruby-gems.org: https://snapcraft.io/ruby -- https://bugs.ruby-lang.org/

2 1

[ruby-core:120859] [Ruby master Bug#21108] C-c (SIGINT) crashes ruby when looping Ractors are not taken?
by osyoyu (Daisuke Aritomo) 06 Jun '25

06 Jun '25

Issue #21108 has been reported by osyoyu (Daisuke Aritomo). ---------------------------------------- Bug #21108: C-c (SIGINT) crashes ruby when looping Ractors are not taken? https://bugs.ruby-lang.org/issues/21108 * Author: osyoyu (Daisuke Aritomo) * Status: Open * ruby -v: ruby 3.5.0dev (2025-01-27T08:19:32Z master c3c7300b89) +PRISM [x86_64-linux] * Backport: 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN, 3.4: UNKNOWN ---------------------------------------- Hitting C-c causes ruby to crash under these circumstances. ## Repro Hit C-c while the program is running. ```ruby r1 = Ractor.new do ary = [] loop do Ractor.receive Ractor.yield ary.push(1) end end r2 = Ractor.new(r1) do |r1| loop do |i| r1.send(nil) r1.take end end # r1.take # `take`ing r1 will fix this issue r2.take ``` ### Expected The process quits. ### Actual An `[BUG] unreachable` occurs. The rb_bug() is called inside `ractor_try_yield`. https://github.com/ruby/ruby/blob/ace39a3ed40cc32ff8d48893173413a7e05b8316/… ``` wrap.rb:1: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. <internal:ractor>:644: [BUG] unreachable ruby 3.5.0dev (2025-01-27T08:19:32Z master c3c7300b89) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0005 p:0003 s:0022 e:000021 METHOD <internal:ractor>:644 c:0004 p:0014 s:0015 e:000014 BLOCK wrap.rb:5 c:0003 p:0017 s:0012 e:000011 METHOD <internal:kernel>:168 c:0002 p:0008 s:0007 e:000006 BLOCK wrap.rb:3 [FINISH] c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- wrap.rb:3:in 'block in <main>' <internal:kernel>:168:in 'loop' wrap.rb:5:in 'block (2 levels) in <main>' <internal:ractor>:644:in 'yield' -- Threading information --------------------------------------------------- Total ractor count: 2 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- ruby(0x639a516dc55a) [0x639a516dc55a] [0x639a512af8dd] [0x639a512a3a31] [0x639a513876a1] [0x639a513877a6] [0x639a5149b0b3] [0x639a51487565] [0x639a514317db] [0x639a51433e71] [0x639a51434295] ``` See full log at: https://gist.github.com/osyoyu/2ae4fe3e41c139703bab5c321a81dda5 -- https://bugs.ruby-lang.org/

3 4

[ruby-core:122471] [Ruby Feature#15854] Tracing instance variable assignment
by st0012 (Stan Lo) 05 Jun '25

05 Jun '25

Issue #15854 has been updated by st0012 (Stan Lo). > I think tracing ivar assignments would be prohibitively slow, and so probably not really usable in practice. Since TracePoint is only recommended for debugging use, I think trading execution speed for more efficient debugging experience is a worth tradeoff for many people (myself included). Currently, tools like `debug` watch events like `call` and `return` to inspect instance variable changes ([example](https://github.com/ruby/debug/blob/master/lib/debug/breakpoint.rb#…) or even line event like the description gives, which are all much slower than having a dedicated ivar set event. Anyway, I made a PR to support it here: https://github.com/ruby/ruby/pull/13369 ---------------------------------------- Feature #15854: Tracing instance variable assignment https://bugs.ruby-lang.org/issues/15854#change-113659 * Author: igaiga (Kuniaki Igarashi) * Status: Assigned * Assignee: ko1 (Koichi Sasada) ---------------------------------------- I suggest a feature "tracing instance variable assignment". It's useful for debugging. Use case: In Rails, we use instance variables in views and controllers. When we got a bug caused by instance variable unintentional values, if we traced instance variable assignment timing, it would be good informations. And in Rails views, there are no source codes of self class. That's built dynamically. Current behavior (Ruby2.6): In Ruby 2.6, only if there is a source code file to assign instance variable, we can trace instance variable assignment by following code (check_instance_variable_assignment.rb). But it's difficult if the assignment codes are defined dynamically. For example, in Rails view. (And in another story, global variables assignment are traced by Kernel#trace_var.) check_instance_variable_assignment.rb ```ruby def trace_start TracePoint.trace(:line) do |tp| target_class_name = "Foo" target_instance_variable_name = "@bar" line = File.open(tp.path, "r"){|f| f.readlines[tp.lineno - 1] } node = RubyVM::AbstractSyntaxTree.parse(line).children.last # check instance variable assignment next unless node.type == :IASGN # check class name target_class = Kernel.const_get(target_class_name) next unless tp.self.is_a?(target_class) # check variable name instance_variable_name = node.children.first next unless instance_variable_name == target_instance_variable_name.to_sym puts "#{target_class_name} #{target_instance_variable_name} is assigned in #{tp.path}:#{tp.lineno} #{tp.defined_class} #{tp.method_id}" end end class Foo def bar @bar = "text" end end trace_start Foo.new.bar #=> Foo @bar is assigned in check_instance_variable_assignment.rb:25 Foo bar ``` Suggesting feature example: Add new arguments for TracePoint.new method like :line and :call to trace instance variables assignment. - :iasgn (IASGN name from RubyVM::AbstractSyntaxTree::Node) - :casgn (CVASGN (or CASGN?) name from RubyVM::AbstractSyntaxTree::Node. I think class variables tracing is useful too.) And get informations - class name (It might be get by trace_point.self) - variable name ("@foo", "@@foo") A sample code to use the feature: tp_iasgn.rb ```ruby TracePoint.trace(:iasgn) do |tp| target_class_name = "Foo" target_instance_variable_name = "@bar" # check class name target_class = Kernel.const_get(target_class_name) next unless tp.self.is_a?(target_class) # check variable name next unless target_instance_variable_name == tp.variable_name puts "#{target_class_name} #{target_instance_variable_name} is assigned in #{tp.path}:#{tp.lineno} #{tp.method_id} #{tp.defined_class}" puts caller # even in dynamic code case, we can get caller informations. end ``` -- https://bugs.ruby-lang.org/

1 0

[ruby-core:122468] [Ruby Bug#17516] forking in a ractor causes Ruby to crash
by jhawthorn (John Hawthorn) 05 Jun '25

05 Jun '25

Issue #17516 has been updated by jhawthorn (John Hawthorn). Right now forking with a block or forking and execing works without crashing ``` ./miniruby -e 'Ractor.new { fork(){} }.take' ``` However as described in the issue forking with no block still crashes. ``` ./miniruby -e 'Ractor.new { fork() }.take' -e:1: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. -e:1: warning: Ractor#take was deprecated and use Ractor#value instead. This method will be removed after the end of Aug 2025 [BUG] rb_thread_terminate_all: called by child thread (0x0000000000000000, 0x00005949b17c44e0) ruby 3.5.0dev (2025-06-05T18:01:41Z master 3e626a6aed) +PRISM [x86_64-linux] -- Control frame information ----------------------------------------------- c:0001 p:---- s:0003 e:000002 DUMMY [FINISH] -- Threading information --------------------------------------------------- Total ractor count: 1 Ruby thread count for this ractor: 1 -- C level backtrace information ------------------------------------------- ``` ---------------------------------------- Bug #17516: forking in a ractor causes Ruby to crash https://bugs.ruby-lang.org/issues/17516#change-113656 * Author: pkmuldoon (Phil Muldoon) * Status: Assigned * Assignee: ractor * ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- I just want to point out, there's absolutely no reason to do this, but r = Ractor.new do Process.fork() end Will cause: <internal:ractor>:267: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues. [BUG] rb_thread_terminate_all: called by child thread (0x0000700004ddca40, 0x00007f981b567ee0) ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20] -- Crash Report log information -------------------------------------------- See Crash Report log file under the one of following: * ~/Library/Logs/DiagnosticReports * /Library/Logs/DiagnosticReports for more details. Don't forget to include the above Crash Report log file in bug reports. -- Control frame information ----------------------------------------------- c:0001 p:---- s:0003 e:000002 (none) [FINISH] -- C level backtrace information ------------------------------------------- => #<Ractor:#3 (pry):5 terminated> [4] pry(main)> /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_vm_bugreport+0x6cf) [0x103084d1f] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_bug_without_die+0x206) [0x102e9e2b6] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_bug+0x71) [0x103091e6b] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_thread_terminate_all+0x329) [0x10301e5b9] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_ractor_terminate_all+0xa3) [0x102f8acc3] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_ec_cleanup+0x229) [0x102ea9299] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(ruby_stop+0x9) [0x102ea9509] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(thread_start_func_2+0x8ce) [0x103027fce] /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(thread_start_func_1+0x10d) [0x10302753d] /usr/lib/system/libsystem_pthread.dylib(_pthread_start+0xe0) [0x7fff20382950] ---Files-------------------------------- ruby_2021-01-06-104315_phillip-muldoon-FA588.crash (31.8 KB) -- https://bugs.ruby-lang.org/

1 0