- ruby-core - ml.ruby-lang.org

[ruby-core:126381] [Ruby Feature#22244] `ruby -UU` should set both internal and external, `ruby -E` should print encoding list
by zenspider (Ryan Davis) 13 Aug '26

13 Aug '26

Issue #22244 has been reported by zenspider (Ryan Davis). ---------------------------------------- Feature #22244: `ruby -UU` should set both internal and external, `ruby -E` should print encoding list https://bugs.ruby-lang.org/issues/22244 * Author: zenspider (Ryan Davis) * Status: Open ---------------------------------------- ``` 10004 $ env -u LANG ruby -U -e 'pp [Encoding.default_internal, Encoding.default_external]' [#<Encoding:UTF-8>, #<Encoding:US-ASCII>] 10005 $ env -u LANG ruby -EUTF-8 -e 'pp [...]' [nil, #<Encoding:UTF-8>] 10006 $ env -u LANG ruby -EUTF-8 -U -e 'pp [...]' [#<Encoding:UTF-8>, #<Encoding:UTF-8>] 10007 $ env -u LANG ruby -EUTF-8:UTF-8 -e 'pp [...]' [#<Encoding:UTF-8>, #<Encoding:UTF-8>] 10008 $ env -u LANG ruby -UU -e 'pp [...]' [#<Encoding:UTF-8>, #<Encoding:US-ASCII>] ``` I think the option processing of encodings is VERY poorly documented and frustrating to try to use. 1. --help doesn't list -U. (The man page does) 2. --help for -E doesn't provide a means to get a list of available encoding names (same with manpage), leading me to try U, UTF8, UTF_8, before finding UTF-8. `ruby -E` could just print them all out. 3. WHY NOT take UTF8 or UTF_8 (since that's the class name)? 4. Please consider `-UU` to mean `-EUTF-8:UTF-8` -- https://bugs.ruby-lang.org/

1 2

[ruby-core:126386] [Ruby Feature#18915] New error class: NotImplementedYetError or scope change for NotImplementedError
by zverok (Victor Shepelev) 13 Aug '26

13 Aug '26

Issue #18915 has been updated by zverok (Victor Shepelev). > The new exception class should inherit from ScriptError, not StandardError. Failing to define a method that a subclass is required to provide is a problem in the program itself, the same kind of problem as SyntaxError or LoadError, not a runtime error. @matz, we just discussed this future change with colleagues (got bit by `NotImplementedError` in our codebase, and I remembered the ongoing core discussion), and I think they made a good counter-argument: **The "this object's method is not implemented" is an error of the same severity class as "this object doesn't have such method at all" (aka `NoMethodError`), and the latter is a descendant of a `StandardError`.** The difference from `SyntaxError`/`LoadError` is that "this method is not implemented" usually happens in runtime, not while the codebase is loaded, and so it not being caught by standard `rescue` might be undesirable. Imagine some code like: ```ruby payloads.each do |payload| driver = Driver.create_for(payload[:type]) # fetches different Driver subclasses driver.process(payload) rescue => ex log.error("payload #{payload} is unprocessable: #{ex.message}") end ``` If we have like 10 different drivers, and one of them didn't implement the necessary method, this will bite the developer somewhere in the middle of the code handling something, not in a "code can't be loaded at all" way. WDYT? ---------------------------------------- Feature #18915: New error class: NotImplementedYetError or scope change for NotImplementedError https://bugs.ruby-lang.org/issues/18915#change-118523 * Author: Quintasan (Michał Zając) * Status: Open ---------------------------------------- # Abstract Introduce `NotImplementedYetError` exception that should be used in case when the codepath has not been implemented by the developer for some reason (maybe they're designing an abstract class or are designing some sort of interface to reuse later on) OR extend the meaning of `NotImplementedError` to cover those usecases so we don't have to introduce another exception # Background `NotImplementedError` is supposed to be raised `if the underlying operating system or Ruby runtime does not support them` (https://ruby-doc.org/core-3.1.2/NotImplementedError.html) However it appears that many people are misusing this exception by raising this in a superclass from which they later inherit from. I do realize that Ruby promotes duck-typing (the default RuboCop style guide has a cop for this – https://github.com/rubocop/ruby-style-guide#duck-typing) However I have seen this being discussed numerous times: * https://github.com/rubocop/ruby-style-guide/issues/458 * http://chrisstump.online/2016/03/23/stop-abusing-notimplementederror/ * https://oleg0potapov.medium.com/ruby-notimplementederror-dont-use-it-dff1fd… * https://gitlab.com/gitlab-org/gitlab/-/issues/354314 (which I'm the author of) * https://github.com/rmosolgo/graphql-ruby/issues/2067 (here the author actually confused it with Python's `NotImplementedError`) * https://stackoverflow.com/questions/13668068/how-to-signal-not-implemented-… # Proposal Create `NotImplementedYetError` exception OR Allow raising `NotImplementedError` in cases other than OS or Ruby runtime incompatibilities # Evaluation ### Add `NotImplementedYetError` I think a new exception is a better idea than changing the usage of an existing one just because "everyone is using it". That said it would require people to refactor their code which might prevent wider adoption of the new exception. ### Change scope of `NotImplementedError` This would require the least amount of changes possible (only a documentation change) and I believe there would be no compatibility problems whatsoever. ---Files-------------------------------- not-implemented-error-docs.patch (1.57 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126383] [Ruby Bug#18444] Trapped TSTP causes a locking deadlock in 3.0.3 onward
by wanabe (_ wanabe) 13 Aug '26

13 Aug '26

Issue #18444 has been updated by wanabe (_ wanabe). File 18444.log added This issue can also be reproduced on the master branch. Since it is not specific to TSTP, it can be reproduced with any signal. ``` $ ./miniruby -ve 'Signal.trap(:TERM) { print "2\r"; sleep 0.01; exit(0) }; spawn("sleep 0.1; kill -TERM #{$$}"); loop {print "1\r"}' ruby 4.1.0dev (2026-08-12T02:39:28Z origin/master c6e9858440) +PRISM [x86_64-linux] -e:1:in 'IO#write': deadlock; recursive locking (ThreadError) from -e:1:in 'Kernel#print' from -e:1:in 'block in <main>' from -e:1:in 'IO#write' from -e:1:in 'Kernel#print' from -e:1:in 'block in <main>' from -e:1:in 'Kernel#loop' from -e:1:in '<main>' ``` I attached the backtrace captured with GDB. Summary: ``` print "1\r" # print in loop{} -> #44 0x00005555557005d5 in io_binwrite (ptr=0x55555606e810 "1\r", len=2, fptr=0x555555f26c40, nosync=0) at ../../io.c:1939 #43 0x000055555589676c in rb_mutex_synchronize (self=140737345534480, func=0x555555700320 <io_binwrite_string>, arg=140737488338256) at ../../thread_sync.c:629 #42 0x00005555556b408c in rb_ec_ensure (ec_arg=0x555555ebff58, b_proc=0x555555700320 <io_binwrite_string>, data1=140737488338256, e_proc_arg=0x555555896318 <do_mutex_unlock_safe>, data2_arg=140737488338176) at ../../eval.c:1171 #40 0x000055555570030a in io_binwrite_string_internal (fptr=0x555555f26c40, ptr=0x55555606e810 "1\r", length=2) at ../../io.c:1817 #38 0x00005555556fdf28 in rb_io_blocking_region_wait (io=0x555555f26c40, function=0x5555556ff0db <internal_write_func>, argument=0x7fffffffbac0, events=RUBY_IO_WRITABLE) at ../../io.c:230 #35 0x000055555589d86e in rb_threadptr_execute_interrupts (th=0x555555ea0780 <_main_thread>, blocking_timing=1) at ../../thread.c:2820 Signal.trap(:TERM) -> #34 0x000055555584688a in rb_signal_exec (th=0x555555ea0780 <_main_thread>, sig=15) at ../../signal.c:1143 #33 0x00005555558466ef in signal_exec (cmd=140737345533960, sig=15) at ../../signal.c:1081 #32 0x00005555559106d9 in rb_eval_cmd_call_kw (cmd=140737345533960, argc=1, argv=0x7fffffffb778, kw_splat=0) at ../../vm_eval.c:2196 print "2\r" # print in trap{} -> #3 0x00005555557005d5 in io_binwrite (ptr=0x55555606e8c0 "2\r", len=2, fptr=0x555555f26c40, nosync=0) at ../../io.c:1939 #2 0x000055555589674a in rb_mutex_synchronize (self=140737345534480, func=0x555555700320 <io_binwrite_string>, arg=140737488328896) at ../../thread_sync.c:628 #1 0x0000555555895bf4 in do_mutex_lock (args=0x7fffffff9870, interruptible_p=1) at ../../thread_sync.c:296 #0 rb_raise (exc_class=93824993755556, fmt=0x7fffffff9710 "@\227\377\377\377\177") at ../../error.c:3930 ``` - Since `rb_signal_exec` is executed - while STDOUT is locked by the `print` statement in the main loop, - a problem occurs when attempting to use `print` within the `trap` block - because STDOUT is still locked. Ideally, this issue could be resolved by ensuring that `rb_signal_exec` is executed only after the lock is released by the first `print` statement in the main loop. But I am concerned that doing so might compromise compatibility. ---------------------------------------- Bug #18444: Trapped TSTP causes a locking deadlock in 3.0.3 onward https://bugs.ruby-lang.org/issues/18444#change-118519 * Author: why-el (Mohamed Wael Khobalatte) * Status: Open * ruby -v: 3.0.3 * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- A curious case: `ruby -e 'Signal.trap("TSTP") { puts "Received a terminal stop signal, but i will sleep instead."; sleep 10 }; loop {puts 1}'` this fails with `deadlock; recursive locking (ThreadError)` when I send the SIGTSTP via my terminal. This is on Mac OS Monterey (M1). It only happens in 3.0.3 and onward (I tried 3.1.0-preview1 as well, fails there too), when I try 3.0.2, the signal is handled properly. ---Files-------------------------------- 18444.log (11.8 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:126210] [Ruby Misc#22221] DevMeeting-2026-08-06
by mame (Yusuke Endoh) 12 Aug '26

12 Aug '26

Issue #22221 has been reported by mame (Yusuke Endoh). ---------------------------------------- Misc #22221: DevMeeting-2026-08-06 https://bugs.ruby-lang.org/issues/22221 * Author: mame (Yusuke Endoh) * Status: Open ---------------------------------------- # The next dev meeting **Date: 2026/08/06 13:00-17:00** (JST) Log: *TBD* - Dev meeting *IS NOT* a decision-making place. All decisions should be done at the bug tracker. - Dev meeting is a place we can ask Matz, nobu, nurse and other developers directly. - Matz is a very busy person. Take this opportunity to ask him. If you can not attend, other attendees can ask instead of you (if attendees can understand your issue). - We will write a record of the discussion in the file or to each ticket in English. - All activities are best-effort (keep in mind that most of us are volunteer developers). - The date, time and place of the meeting are scheduled according to when/where we can reserve Matz's time. - *DO NOT* discuss then on this ticket, please. # Call for agenda items If you have a ticket that you want matz and committers to discuss, please post it into this ticket in the following format: ``` * [Ticket ref] Ticket title (your name) * Comment (A summary of the ticket, why you put this ticket here, what point should be discussed, etc.) ``` Example: ``` * [Feature #14609] `Kernel#p` without args shows the receiver (ko1) * I feel this feature is very useful and some people say :+1: so let discuss this feature. ``` - It is recommended to add a comment by 2026/08/03. We hold a preparatory meeting to create an agenda a few days before the dev-meeting. - The format is strict. We'll use [this script to automatically create an markdown-style agenda](https://gist.github.com/mame/b0390509ce1491b43610b9ebb665eb86). We may ignore a comment that does not follow the format. - Your comment is mandatory. We cannot read all discussion of the ticket in a limited time. We appreciate it if you could write a short summary and update from a previous discussion. -- https://bugs.ruby-lang.org/

11 15

[ruby-core:121829] [Ruby Feature#21308] Replacing the Float#to_s (dtoa.c) implementation with a modern algorithm
by watson1978 (Shizuo Fujita) 12 Aug '26

12 Aug '26

Issue #21308 has been reported by watson1978 (Shizuo Fujita). ---------------------------------------- Feature #21308: Replacing the Float#to_s (dtoa.c) implementation with a modern algorithm https://bugs.ruby-lang.org/issues/21308 * Author: watson1978 (Shizuo Fujita) * Status: Open ---------------------------------------- This is a feature request to replace Ruby's `Float#to_s` implementation with a modern high-performance float-to-string conversion algorithm such as Grisu. Currently, `Float#to_s` in Ruby uses the BSD-derived implementation in [missing/dtoa.c](https://github.com/ruby/ruby/blob/master/missing/dtoa.c). Meanwhile, `json` gem has adopted a Grisu-based implementation in [ruby/json#768](https://github.com/ruby/json/pull/768), it has been improve the performance of float-to-string conversion dramatically. It appears to have brought about a 10 times improvement in performance. However, the improvement is limited to the `json` gem. If we can use the same implementation in `Float#to_s`, it will introduce the improvement in all float-to-string conversion cases. (In additional, it would be better if an API could be added that could be called directly from the C extension library, it will reduce the overhead of the call.) -- https://bugs.ruby-lang.org/

3 3

[ruby-core:126369] [Ruby Bug#22241] Restore compatibility for removed `JSON.dump` and `JSON.parse` arguments
by nobu (Nobuyoshi Nakada) 12 Aug '26

12 Aug '26

Issue #22241 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #22241: Restore compatibility for removed `JSON.dump` and `JSON.parse` arguments https://bugs.ruby-lang.org/issues/22241 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Assignee: byroot (Jean Boussier) * Target version: 4.1 * ruby -v: f51515f39a13223ce784eb3412c1f83a8a3960a4 * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- JSON 3.0.0.rc1 removes two previously accepted arguments without a deprecation period: ```ruby JSON.dump(object, io, 0) JSON.parse(source, quirks_mode: true) ``` The first call now raises `TypeError` because the third positional argument is treated as an options hash. The second raises `ArgumentError` because `quirks_mode` is no longer recognized. Neither usage produces a deprecation warning with JSON 2.21.2, even with warnings enabled: ```ruby Warning[:deprecated] = true ``` This currently breaks downstream test suites. RDoc used the third `JSON.dump` argument when generating its JSON index, while `json-schema` 5.1.0 passes `quirks_mode: true`, causing RBS schema tests in the Ruby repository to fail. Because JSON is a default gem, downstream projects cannot always avoid the breakage by pinning an older version, especially when testing against Ruby head. Could JSON 3.0 continue accepting these arguments for compatibility? `quirks_mode` can presumably be accepted and ignored now that top-level scalar values are parsed by default. The positional `limit` argument could similarly remain supported until it has gone through a deprecation cycle. -- https://bugs.ruby-lang.org/

2 5

[ruby-core:126360] [Ruby Bug#22239] Multiple buffer clear errors in IO
by YO4 (Yoshinao Muramatsu) 10 Aug '26

10 Aug '26

Issue #22239 has been reported by YO4 (Yoshinao Muramatsu). ---------------------------------------- Bug #22239: Multiple buffer clear errors in IO https://bugs.ruby-lang.org/issues/22239 * Author: YO4 (Yoshinao Muramatsu) * Status: Open * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- While testing my changes on the Windows platform to use an encoding converter for newline conversion for "r", I discovered a failure in test_reopen. This corresponds to case (3) below. I asked an LLM to investigate similar cases and related code that raised concerns, and was able to identify several issues, so I am reporting them here. I'll submit a PR later. I used Hy3 (High) via opencode GO to perform this survey and create the test code. (For transparency—this is not an advertisement.) case(1) In io.c, free_io_buffer only clears ptr and left off, len and capa as they were. Since clear_readconv releases the character buffer through it, READ_CHAR_PENDING() kept reporting pending characters after the buffer had been released. As a result, every operation that clears the code converter (IO#rewind, IO#seek, IO#pos=, IO#flush, IO#binmode, IO#tell, IO#set_encoding, ...) left the IO in a state where byte oriented reads raise IOError. Also IO#eof? answers false at the end of file and IO#sysseek refuses to work. ``` File.binwrite("t", "foo") open("t", "rt") do |f| f.ungetc(f.getc) f.rewind f.getbyte # => 'IO#getbyte': byte oriented read for character buffered IO (IOError) end ``` case(2) IO#reopen(io) only flushes the write buffer when the IO is writable, and never unreads the read buffer. The buffer happens to be dropped by the io_seek after dup2, but only when the other stream is readable and seekable, so a read-write IO keeps stale bytes otherwise. ``` File.binwrite("t", "0123456789") f = File.open("t", "r+b") f.getbyte IO.pipe do |r, w| w.write("ABC"); w.close f.reopen(r) f.read # => "123456789ABC" instead of "ABC" end ``` case(3) IO#reopen(name) discards the byte buffer but keeps the code converter and the character buffer, so characters left over from the previous stream leak into the reopened one. ``` File.binwrite("t", "foo") open(File::NULL, "rt") do |f| f.ungetc("a") f.reopen("t") f.read # => "afoo" instead of "foo" end ``` case(4) IO#reopen(io) relies on flush_before_seek to drop the buffers, but io_unread returns at once when rbuf is empty and therefore never reaches clear_codeconv. With characters pending in cbuf and nothing in rbuf they leak into the reopened stream. ``` File.write("t", "foo\n") open(File::NULL, "rt") do |f| f.ungetc("a") open("t", "rt") {|f2| f.reopen(f2)} f.gets # => "afoo\n" instead of "foo\n" end ``` case(5) Unlike IO#rewind, IO#seek and IO#pos= do not clear the character buffer. As io_unread returns at once when rbuf is empty, an ungotten character survives the repositioning while it does not in binary mode. ``` File.write("t", "foo\n") open("t", "rt") do |f| f.ungetc("a") f.seek(2, :SET) f.getc # => "a" instead of "o" end ``` -- https://bugs.ruby-lang.org/

1 1

[ruby-core:125818] [Ruby Bug#22126] Stack underflow for partial DCE and loops
by viralpraxis (Iaroslav Kurbatov) 10 Aug '26

10 Aug '26

Issue #22126 has been reported by viralpraxis (Iaroslav Kurbatov). ---------------------------------------- Bug #22126: Stack underflow for partial DCE and loops https://bugs.ruby-lang.org/issues/22126 * Author: viralpraxis (Iaroslav Kurbatov) * Status: Open * ruby -v: ruby 4.1.0dev (2026-06-23T13:29:36Z master 13fe77dd2b) +PRISM [x86_64-linux] * Backport: 3.3: UNKNOWN, 3.4: UNKNOWN, 4.0: UNKNOWN ---------------------------------------- ``` ruby ruby --parser prism -e 'if []; else; a => [*, 42, *]; end' -- raw disasm-------- trace: 1 0000 putnil ( 1) 0001 leave ( 1) <L018> [sp: 1, unremovable: 0, refcnt: 1] 0002 dup ( 1) 0003 topn 2 ( 1) 0005 opt_le <calldata:<=, 1> ( 1) 0007 branchunless <L021> ( 1) 0009 topn 3 ( 1) 0011 topn 1 ( 1) 0013 opt_aref <calldata:[], 1> ( 1) 0015 putobject 42 ( 1) 0017 dupn 2 ( 1) 0019 checkmatch 2 ( 1) 0021 dup ( 1) 0022 branchif <L023> ( 1) 0024 putspecialobject 1 ( 1) 0026 putobject "%p === %p does not return true" ( 1) 0028 topn 3 ( 1) 0030 topn 5 ( 1) 0032 opt_send_without_block <calldata:core#sprintf, 3> ( 1) 0034 setn 10 ( 1) 0036 putobject false ( 1) 0038 setn 12 ( 1) 0040 pop ( 1) 0041 pop ( 1) <L023> [sp: 4, unremovable: 0, refcnt: 1] 0042 setn 2 ( 1) 0044 pop ( 1) 0045 pop ( 1) 0046 branchif <L020> ( 1) 0048 putobject_INT2FIX_1_ ( 1) 0049 opt_plus <calldata:+, 1> ( 1) 0051 jump <L018> ( 1) <L021> [sp: 1, unremovable: 0, refcnt: 1] * 0053 adjuststack 3 ( 1) 0055 putspecialobject 1 ( 1) 0057 putobject "%p does not match to find pattern" ( 1) 0059 topn 2 ( 1) 0061 opt_send_without_block <calldata:core#sprintf, 2> ( 1) 0063 setn 4 ( 1) 0065 putobject false ( 1) 0067 setn 6 ( 1) 0069 pop ( 1) 0070 pop ( 1) 0071 jump <L012> ( 1) <L020> [sp: 1, unremovable: 0, refcnt: 1] 0073 adjuststack 3 ( 1) 0075 pop ( 1) 0076 jump <L003> ( 1) <L012> [sp: -1, unremovable: 0, refcnt: 1] 0078 pop ( 1) 0079 putspecialobject 1 ( 1) 0081 topn 4 ( 1) 0083 branchif <L024> ( 1) 0085 putobject NoMatchingPatternError ( 1) 0087 putspecialobject 1 ( 1) 0089 putobject "%p: %s" ( 1) 0091 topn 4 ( 1) 0093 topn 7 ( 1) 0095 opt_send_without_block <calldata:core#sprintf, 3> ( 1) 0097 opt_send_without_block <calldata:core#raise, 2> ( 1) 0099 jump <L025> ( 1) <L024> [sp: -1, unremovable: 0, refcnt: 1] 0101 putobject NoMatchingPatternKeyError ( 1) 0103 putspecialobject 1 ( 1) 0105 putobject "%p: %s" ( 1) 0107 topn 4 ( 1) 0109 topn 7 ( 1) 0111 opt_send_without_block <calldata:core#sprintf, 3> ( 1) 0113 topn 7 ( 1) 0115 topn 9 ( 1) 0117 opt_send_without_block <calldata:new, 3> ( 1) 0119 opt_send_without_block <calldata:core#raise, 1> ( 1) <L025> [sp: -1, unremovable: 0, refcnt: 1] 0121 adjuststack 7 ( 1) 0123 putnil ( 1) 0124 leave ( 1) <L003> [sp: -1, unremovable: 0, refcnt: 1] 0125 adjuststack 6 ( 1) 0127 putnil ( 1) 0128 leave ( 1) --------------------- -e:1: argument stack underflow (-2) -e: compile error (SyntaxError) ``` proposed patch: https://github.com/ruby/ruby/pull/17449 every version since 3.4.0-preview2 is affected -- https://bugs.ruby-lang.org/

5 5

[ruby-core:126263] [Ruby Feature#22229] Allow GCI.escapeHTML to take a custom escape table
by byroot (Jean Boussier) 10 Aug '26

10 Aug '26

Issue #22229 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #22229: Allow GCI.escapeHTML to take a custom escape table https://bugs.ruby-lang.org/issues/22229 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Use case `CGI.escapeHTML` has a fixed escape table: ```c HTML_ESCAPE('\'', "'"), HTML_ESCAPE('&', "&"), HTML_ESCAPE('"', """), HTML_ESCAPE('<', "<"), HTML_ESCAPE('>', ">"), ``` But in some context you may want to escape more or less characters than that, or escape them differently. One example of this is Active Support JSON serialization, which by defaults escape `<>&` as `\u003e\u003c\u0026`, to ensure that the generated JSON can safely be interpolated inside a `<script>` tag without causing XSS vulnerabilities. There's likely other use case as evidenced by the popularity of the `htmlentities` gem, which support several more escape tables. ### Why not `gsub` ? Today, this sort of escaping is performed using `gsub`, it works but is very noticeably slower than `CGI.escapeHTML` (see benchmarks on the PoC PR). This is because the only way to use `gsub` with an escape table is to craft a regexp: ```ruby def escape(string, table) pattern = Regexp.union(table.keys) string.gsub(pattern, table) end puts escape("<script>", "<" => "<", ">" => ">") ``` If `gsub` could be used directly with the escape table it would certainly make it faster: ```ruby puts "<script>".gsub("<" => "<", ">" => ">") ``` But compared to `CGI.escapeHTML` it would still need to deal with noticeably more scenarios (multi character search, etc), so would always be slower than a dedicated escaping method. `CGI.escapeHTML` can be more restrictive (single character search, etc). ### Specification ```ruby GCI.escapeHTML("</script>", "<" => "<", ">" => ">") ``` - The escape table keys must be single characters (currently ASCII only, but could be muti-byte characters if deemed necessary). ### Implementation ``` Pull Request: https://github.com/ruby/cgi/pull/55 (NB: it's at proof of concept / demo stage, if the feature is accepted I can polish it). -- https://bugs.ruby-lang.org/

3 6

[ruby-core:126355] [Ruby Bug#15599] Mixing autoload and require causes deadlock and incomplete definition.
by wanabe (_ wanabe) 10 Aug '26

10 Aug '26

Issue #15599 has been updated by wanabe (_ wanabe). Status changed from Open to Closed This issue was fixed between preview 2 and preview 3 of Ruby 3.3.0. ``` $ cat a.rb class A def a1() end end $ cat base.rb 1000.times do fork do autoload :A, './a' t1 = Thread.new { raise if A.instance_methods(false).size != 1 } t2 = Thread.new { require './a' } begin t1.join t2.join rescue Exception => e exit 1 end end end p Process.waitall.map {|_pid, status| status.success? ? :success : :failure }.group_by(&:itself).transform_values(&:size).to_a puts :fin $ docker run -it --rm -v.:/work -w/work --env ALL_RUBY_SINCE=3.2.10 rubylang/all-ruby /all-ruby/all-ruby base.rb ruby-3.2.10 #<Thread:0x00007119bd008e88 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception #<Thread:0x00007119bd008e88 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception #<Thread:0x00007119bd008e88 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception #<Thread:0x00007119bd008e88 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception [[:success, 921], [:failure, 79]] fin ruby-3.2.11 #<Thread:0x00007eb67a448f68 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception [[:success, 922], [:failure, 78]] fin ruby-3.3.0-preview1 #<Thread:0x00007429d36e67e0 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception [[:success, 931], [:failure, 69]] fin ruby-3.3.0-preview2 #<Thread:0x0000751915115f78 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception #<Thread:0x0000751915115f78 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception #<Thread:0x0000751915115f78 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception #<Thread:0x0000751915115f78 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception #<Thread:0x0000751915115f78 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception #<Thread:0x0000751915115f78 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception #<Thread:0x0000751915115f78 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception #<Thread:0x0000751915115f78 base.rb:5 run> terminated with exception (report_on_exception is true): base.rb:5:in `block (3 levels) in <main>': unhandled exception [[:success, 904], [:failure, 96]] fin ruby-3.3.0-preview3 [[:success, 1000]] fin ... ruby-4.0.6 [[:success, 1000]] fin ``` I found the commit is be1bbd5b7d40ad863ab35097765d3754726bbd54 == https://bugs.ruby-lang.org/issues/19842. I don't know why this is the case, but I suspect that the refactoring done to achieve the original goal (M:N threads) had a positive effect. ``` $ git checkout be1bbd5b7d40ad863ab35097765d3754726bbd54~ && make -j miniruby >/dev/null 2>&1 && ./miniruby base.rb HEAD is now at 096ee0648e2 Bump ruby/setup-ruby from 1.155.0 to 1.156.0 [[:success, 945], [:failure, 55]] fin $ git checkout be1bbd5b7d40ad863ab35097765d3754726bbd54 && make -j miniruby >/dev/null 2>&1 && ./miniruby base.rb Previous HEAD position was 096ee0648e2 Bump ruby/setup-ruby from 1.155.0 to 1.156.0 HEAD is now at be1bbd5b7d4 M:N thread scheduler for Ractors [[:success, 1000]] fin ``` ---------------------------------------- Bug #15599: Mixing autoload and require causes deadlock and incomplete definition. https://bugs.ruby-lang.org/issues/15599#change-118480 * Author: akr (Akira Tanaka) * Status: Closed * ruby -v: ruby 2.7.0dev (2019-02-11 trunk 67049) [x86_64-linux] * Backport: 2.4: UNKNOWN, 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- I found that mixing autoload and require causes deadlock and incomplete definition. ``` % cat a.rb class A def a1() end end % cat base.rb autoload :A, './a' t1 = Thread.new { p A.instance_methods(false) } t2 = Thread.new { require './a' } t1.join t2.join % ruby base.rb Traceback (most recent call last): 1: from base.rb:6:in `<main>' base.rb:6:in `join': No live threads left. Deadlock? (fatal) 3 threads, 3 sleeps current:0x000055cc6943fde0 main thread:0x000055cc6935f4b0 * #<Thread:0x000055cc6938f190 sleep_forever> rb_thread_t:0x000055cc6935f4b0 native:0x00007f58d256eb40 int:0 base.rb:6:in `join' base.rb:6:in `<main>' * #<Thread:0x000055cc6968cfc8@base.rb:3 sleep_forever> rb_thread_t:0x000055cc69736180 native:0x00007f58ce7b3700 int:0 mutex:0x000055cc6943fde0 cond:1 depended by: tb_thread_id:0x000055cc6935f4b0 /home/akr/ruby/o0/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:54:in `require' /home/akr/ruby/o0/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:54:in `require' base.rb:3:in `block in <main>' * #<Thread:0x000055cc6968ccd0@base.rb:4 sleep_forever> rb_thread_t:0x000055cc6943fde0 native:0x00007f58ce5b1700 int:0 /tmp/a/a.rb:1:in `<top (required)>' /home/akr/ruby/o0/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:54:in `require' /home/akr/ruby/o0/lib/ruby/2.7.0/rubygems/core_ext/kernel_require.rb:54:in `require' base.rb:4:in `block in <main>' % ruby base.rb [:a1] % ruby base.rb [] ``` The last run which prints [] means incomplete definition of A which a1 method is not defined. -- https://bugs.ruby-lang.org/

1 0