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

[ruby-core:114024] [Ruby master Bug#18743] Enumerator#next / peek re-use each others stacktraces
by marcper (Marcelo Pereira) 26 Jun '23

26 Jun '23

Issue #18743 has been updated by marcper (Marcelo Pereira). Oh, I understood from Matz's initial suggestion that the exceptions should be chained, but I see now what he meant. I've applied the changes you suggested, @nobu. Thank you for clarifying, and for reviewing. ---------------------------------------- Bug #18743: Enumerator#next / peek re-use each others stacktraces https://bugs.ruby-lang.org/issues/18743#change-103688 * Author: sos4nt (Stefan Schüßler) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- I encountered an odd behavior. If I rescue the `StopIteration` exception from `peek` and call `next` afterwards: (or vice-versa) ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next # 5 ``` it will show the stacktrace from the rescued `peek` call: ``` $ ruby enum.rb enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` Whereas the error should refer to `next` on line number 5. The same happens when calling `peek` after `next` or when having muliple `peek` / `next` calls: ```ruby # enum.rb # 1 # 2 enum = [].each # 3 enum.peek rescue nil # 4 enum.next rescue nil # 5 enum.peek rescue nil # 6 puts "line #{__LINE__}" # 7 enum.next # 8 ``` The stacktrace from the first (rescued) `peek` or `next` call will be shown which doesn't reflect the actual error location: ``` $ ruby enum.rb line 7 enum.rb:4:in `peek': iteration reached an end (StopIteration) from enum.rb:4:in `<main>' ``` This is very confusing when debugging code. ---Files-------------------------------- 01-Recreate-stacktrace-enumerator.patch (1.29 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114021] [Ruby master Bug#18464] RUBY_INTERNAL_EVENT_NEWOBJ tracepoint causes an interpreter crash when combined with Ractors
by nagachika (Tomoyuki Chikanaga) 25 Jun '23

25 Jun '23

Issue #18464 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 2.6: DONTNEED, 2.7: DONTNEED, 3.0: REQUIRED, 3.1: DONE, 3.2: REQUIRED to 2.6: DONTNEED, 2.7: DONTNEED, 3.0: REQUIRED, 3.1: DONE, 3.2: DONE ruby_3_2 b422c3523c419b88c6da23a4022ae8864f411b84 merged revision(s) 7bd7aee02e303de27d2cddfc5ef47e612d6782cb. ---------------------------------------- Bug #18464: RUBY_INTERNAL_EVENT_NEWOBJ tracepoint causes an interpreter crash when combined with Ractors https://bugs.ruby-lang.org/issues/18464#change-103684 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Closed * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-darwin20] * Backport: 2.6: DONTNEED, 2.7: DONTNEED, 3.0: REQUIRED, 3.1: DONE, 3.2: DONE ---------------------------------------- When a Ractor is created whilst a tracepoint for `RUBY_INTERNAL_EVENT_NEWOBJ` is active (registered with `rb_tracepoint_new`/`rb_tracepoint_enabled`), the interpreter crashes with a null pointer dereference with the following backtrace: ``` [BUG] Segmentation fault at 0x0000000000000000 ruby 3.1.0p0 (2021-12-25 revision fb4df44d16) [x86_64-darwin20] ... -- C level backtrace information ------------------------------------------- /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_print_backtrace+0xf) [0x10a15fadd] vm_dump.c:759 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_vm_bugreport) vm_dump.c:1045 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_vm_bugreport) (null):0 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(bug_report_end+0x0) [0x109f96b81] error.c:820 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_bug_for_fatal_signal) error.c:820 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(sigsegv+0x52) [0x10a0be3a2] signal.c:964 /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x1d) [0x7fff20934d7d] /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(gc_event_hook_body+0x4) [0x109fb9d21] gc.c:2214 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_slowpath) gc.c:2486 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_slowpath_wb_unprotected) gc.c:2507 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_fill+0x0) [0x109fac92e] gc.c:2543 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_of0) gc.c:2553 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(newobj_of) gc.c:2552 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_wb_unprotected_newobj_of) gc.c:2567 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(io_alloc+0x12) [0x109fd341c] io.c:1047 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(prep_io) io.c:8483 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(prep_stdio) io.c:8514 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_io_prep_stdin) io.c:8532 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(thread_start_func_2+0xf7) [0x10a1058a7] thread.c:802 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(rb_native_cond_initialize+0x0) [0x10a1055fb] ./thread_pthread.c:1047 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(register_cached_thread_and_wait) ./thread_pthread.c:1099 /Users/ktsanaktsidis/Code/zendesk/ruby/ruby(thread_start_func_1) ./thread_pthread.c:1054 /usr/lib/system/libsystem_pthread.dylib(_pthread_start+0xe0) [0x7fff208ef8fc] ``` (full output is attached). This seems to be because the new Ractor sets up stdio objects (`rb_io_prep_stdin` et. al.), which in turn allocate Ruby objects, before `rb_ec_initialize_vm_stack` is called to set up the initial stack frame. I've attached a patch which works around this by not firing GC event hooks if there is no control frame on the execution context. The patch also includes a test which reproduces the issue using the `objspace` extension; creating a Ractor within an `ObjectSpace.trace_object_allocations` block is enough to trigger the crash. The patch seems to fix things, but if you folk prefer I can also try swapping around the order of `prep_stdio` and `rb_ec_initialize_vm_stack`. ---Files-------------------------------- 0001-Fix-interpreter-crash-caused-by-RUBY_INTERNAL_EVENT_.patch (1.91 KB) crash.log (26.1 KB) ruby_2022-01-08-151326_8927-ktsanaktsidis.crash (18.8 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:112871] [Ruby master Bug#19529] [BUG] ObjectSpace::WeakMap can segfault after compaction
by byroot (Jean Boussier) 25 Jun '23

25 Jun '23

Issue #19529 has been reported by byroot (Jean Boussier). ---------------------------------------- Bug #19529: [BUG] ObjectSpace::WeakMap can segfault after compaction https://bugs.ruby-lang.org/issues/19529 * Author: byroot (Jean Boussier) * Status: Open * Priority: Normal * ruby -v: 3.2.1, 2.7.5p203 * Backport: 2.7: WONTFIX, 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- Reproduction script: ```ruby wm = ObjectSpace::WeakMap.new obj = Object.new 100.times do |i| GC.compact wm[i] = obj # [BUG] Segmentation fault at 0x0000000000000001 end ``` Crash report: ``` /tmp/weakmap.rb:5: [BUG] Segmentation fault at 0x0000000000000003 ruby 3.2.1 (2023-02-08 revision 31819e82c8) [arm64-darwin22] -- 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:0005 p:---- s:0023 e:000022 CFUNC :[]= c:0004 p:0016 s:0017 e:000015 BLOCK /tmp/weakmap.rb:5 [FINISH] c:0003 p:---- s:0012 e:000011 CFUNC :times c:0002 p:0017 s:0008 E:0025b0 EVAL /tmp/weakmap.rb:3 [FINISH] c:0001 p:0000 s:0003 E:0010b0 DUMMY [FINISH] -- Ruby level backtrace information ---------------------------------------- /tmp/weakmap.rb:3:in `<main>' /tmp/weakmap.rb:3:in `times' /tmp/weakmap.rb:5:in `block in <main>' /tmp/weakmap.rb:5:in `[]=' -- Machine register context ------------------------------------------------ x0: 0x000000016da8a6b0 x1: 0x000000016da8a6a8 x2: 0x000000000000003d x3: 0x0000000000000001 x4: 0x0000000000000000 x5: 0x0000000000000b00 x6: 0x0000600002db4b00 x7: 0x0000000000000000 x18: 0x0000000000000000 x19: 0x000000016da8a6a8 x20: 0x000000000000003d x21: 0x0000000000000003 x22: 0x0000000000000001 x23: 0x00000001023df7b8 x24: 0x0000000000000001 x25: 0x0000000000000000 x26: 0x00006000027bdf80 x27: 0xffffffffffffffff x28: 0xffffffffffffffff lr: 0x0000000102ca28f0 fp: 0x000000016da8a680 sp: 0x000000016da8a640 -- C level backtrace information ------------------------------------------- /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_vm_bugreport+0x9a0) [0x102d3ba98] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_bug_for_fatal_signal+0x160) [0x102b5fe14] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(sig_do_nothing+0x0) [0x102c9a354] /usr/lib/system/libsystem_platform.dylib(_sigtramp+0x38) [0x19b63c2a4] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_st_update+0x328) [0x102ca28f0] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_st_update+0x328) [0x102ca28f0] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(wmap_aset+0x90) [0x102b88e9c] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_call_cfunc_with_frame+0xe8) [0x102d2fc7c] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_sendish+0x4cc) [0x102d31fdc] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_exec_core+0x239c) [0x102d136c8] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_vm_exec+0xad4) [0x102d26bf0] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(invoke_block_from_c_bh+0x398) [0x102d36438] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_yield_1+0x7c) [0x102d1f208] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(int_dotimes+0x148) [0x102bff3ec] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_call_cfunc_with_frame+0xe8) [0x102d2fc7c] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_sendish+0x4cc) [0x102d31fdc] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(vm_exec_core+0x2350) [0x102d1367c] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_vm_exec+0xad4) [0x102d26bf0] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(rb_ec_exec_node+0x12c) [0x102b6b4ac] /opt/rubies/3.2.1/lib/libruby.3.2.dylib(ruby_run_node+0x60) [0x102b6b318] /opt/rubies/3.2.1/bin/ruby(main+0x68) [0x102377f34] ``` Seems to happens since 2.7. -- https://bugs.ruby-lang.org/

6 11

[ruby-core:111735] [Ruby master Bug#19323] Integer overflow in `Integer#<<`
by nobu (Nobuyoshi Nakada) 25 Jun '23

25 Jun '23

Issue #19323 has been reported by nobu (Nobuyoshi Nakada). ---------------------------------------- Bug #19323: Integer overflow in `Integer#<<` https://bugs.ruby-lang.org/issues/19323 * Author: nobu (Nobuyoshi Nakada) * Status: Open * Priority: Normal * Backport: 2.7: REQUIRED, 3.0: REQUIRED, 3.1: REQUIRED, 3.2: REQUIRED ---------------------------------------- ```ruby require 'rbconfig/sizeof' char_bit = RbConfig::LIMITS["UCHAR_MAX"].bit_length size_max = RbConfig::LIMITS["SIZE_MAX"] size_bit_max = size_max * char_bit 1 << size_bit_max ``` The above code raises an "integer overflow" error. ``` -:5:in `<<': integer overflow: 4611686018427387905 * 4 > 18446744073709551615 (ArgumentError) from -:5:in `<main>' ``` It doesn't seem like a proper or intentional exception. -- https://bugs.ruby-lang.org/

3 3

[ruby-core:114017] [Ruby master Bug#19307] Fix `OpenSSL::X509::CertificateError: invalid digest` on CentOS 9 / RHEL 9
by nagachika (Tomoyuki Chikanaga) 24 Jun '23

24 Jun '23

Issue #19307 has been updated by nagachika (Tomoyuki Chikanaga). Backport changed from 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: REQUIRED to 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: DONE ruby_3_2 9fca561980c6d024229d72600180b20f3f77536f merged revision(s) cd5e6cc0ea48353c88d921b885b552dc76da255c,bbf54ec334fe2edd7669a944d88d17efde49a412. ---------------------------------------- Bug #19307: Fix `OpenSSL::X509::CertificateError: invalid digest` on CentOS 9 / RHEL 9 https://bugs.ruby-lang.org/issues/19307#change-103679 * Author: vo.x (Vit Ondruch) * Status: Closed * Priority: Normal * ruby -v: ruby 3.2.0 (2022-12-25 revision a528908271) [x86_64-linux] * Backport: 2.7: DONTNEED, 3.0: DONTNEED, 3.1: DONTNEED, 3.2: DONE ---------------------------------------- CentOS 9 / RHEL 9 requires prohibits SHA1 for signing purposes, therefore these specs fail: ~~~ 1) OpenSSL::X509::Name.verify returns true for valid certificate ERROR OpenSSL::X509::CertificateError: invalid digest /builddir/build/BUILD/ruby-3.2.0/spec/ruby/library/openssl/x509/name/verify_spec.rb:15:in `sign' /builddir/build/BUILD/ruby-3.2.0/spec/ruby/library/openssl/x509/name/verify_spec.rb:15:in `block (2 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.2.0/spec/ruby/library/openssl/x509/name/verify_spec.rb:4:in `<top (required)>' 2) OpenSSL::X509::Name.verify returns false for an expired certificate ERROR OpenSSL::X509::CertificateError: invalid digest /builddir/build/BUILD/ruby-3.2.0/spec/ruby/library/openssl/x509/name/verify_spec.rb:31:in `sign' /builddir/build/BUILD/ruby-3.2.0/spec/ruby/library/openssl/x509/name/verify_spec.rb:31:in `block (2 levels) in <top (required)>' /builddir/build/BUILD/ruby-3.2.0/spec/ruby/library/openssl/x509/name/verify_spec.rb:4:in `<top (required)>' ~~~ I have opened PR [here](https://github.com/ruby/spec/pull/990), but I'd also like see this backported into 3.2, hence also reporting here. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114015] [Ruby master Bug#18605] Fails to run on (newer) 32bit Windows with ucrt
by awhitenose (Alex Whitenose) 23 Jun '23

23 Jun '23

Issue #18605 has been updated by awhitenose (Alex Whitenose). I have created a simple fix which helped to run 32-bit Ruby 2.6.x up to 3.2.x on Windows 11 without getting 'unexpected ucrtbase.dll' anymore. Available here: https://github.com/oneclick/rubyinstaller2/issues/308#issuecomment-16051252… 64-bit is unaffected. But it obviously does not make any changes or help for ARM builds. ---------------------------------------- Bug #18605: Fails to run on (newer) 32bit Windows with ucrt https://bugs.ruby-lang.org/issues/18605#change-103677 * Author: lazka (Christoph Reiter) * Status: Open * Priority: Normal * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- 32bit ruby using ucrt has started to fail on newer Windows with "unexpected ucrtbase.dll" -> https://github.com/ruby/ruby/blob/3fb7d2cadc18472ec107b14234933b017a33c14d/… The problem is that ruby depends on ucrt internals and those have apparently changed with newer versions. See https://github.com/msys2/MINGW-packages/pull/10878 and https://github.com/msys2/MINGW-packages/issues/10896 for some background and a potential fix. But ideally ruby wouldn't depend on Windows internals like this. thanks! -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114014] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.
by kamil-gwozdz 23 Jun '23

23 Jun '23

Issue #19057 has been updated by kamil-gwozdz (Kamil Gwóźdź). byroot (Jean Boussier) wrote in #note-17: > @ioquatix I'm not sure which change exactly is the cause, but it appears that the recent `rb_io_t` changes broke `raindrops` I've noticed the same thing while trying to install `kgio` with the latest ruby HEAD. {{collapse ``` make DESTDIR\= sitearchdir\=./.gem.20230623-102030-g2vcyh sitelibdir\=./.gem.20230623-102030-g2vcyh compiling accept.c In file included from accept.c:7: my_fileno.h:9:7: warning: "HAVE_RB_IO_T" is not defined, evaluates to 0 [-Wundef] 9 | #if ! HAVE_RB_IO_T | ^~~~~~~~~~~~ my_fileno.h:16:8: warning: "HAVE_RB_IO_T" is not defined, evaluates to 0 [-Wundef] 16 | # if !HAVE_RB_IO_T || (RUBY_VERSION_MAJOR == 1 && RUBY_VERSION_MINOR == 8) | ^~~~~~~~~~~~ my_fileno.h: In function ‘my_fileno’: my_fileno.h:10:19: error: unknown type name ‘OpenFile’; did you mean ‘GetOpenFile’? 10 | # define rb_io_t OpenFile | ^~~~~~~~ my_fileno.h:25:2: note: in expansion of macro ‘rb_io_t’ 25 | rb_io_t *fptr; | ^~~~~~~ In file included from kgio.h:6, from accept.c:4: /workspaces/project/vendor/ruby/30c1fc4087744da4dcc1138e23cf43118e10f5af/include/ruby-3.3.0+0/ruby/io.h:395:55: warning: assignment to ‘int *’ from incompatible pointer type ‘struct rb_io *’ [-Wincompatible-pointer-types] 395 | #define RB_IO_POINTER(obj,fp) rb_io_check_closed((fp) = RFILE(rb_io_taint_check(obj))->fptr) | ^ /workspaces/project/vendor/ruby/30c1fc4087744da4dcc1138e23cf43118e10f5af/include/ruby-3.3.0+0/ruby/io.h:401:21: note: in expansion of macro ‘RB_IO_POINTER’ 401 | #define GetOpenFile RB_IO_POINTER | ^~~~~~~~~~~~~ my_fileno.h:30:2: note: in expansion of macro ‘GetOpenFile’ 30 | GetOpenFile(io, fptr); | ^~~~~~~~~~~ /workspaces/project/vendor/ruby/30c1fc4087744da4dcc1138e23cf43118e10f5af/include/ruby-3.3.0+0/ruby/io.h:395:55: warning: passing argument 1 of ‘rb_io_check_closed’ from incompatible pointer type [-Wincompatible-pointer-types] 395 | #define RB_IO_POINTER(obj,fp) rb_io_check_closed((fp) = RFILE(rb_io_taint_check(obj))->fptr) | ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | | | int * /workspaces/project/vendor/ruby/30c1fc4087744da4dcc1138e23cf43118e10f5af/include/ruby-3.3.0+0/ruby/io.h:401:21: note: in expansion of macro ‘RB_IO_POINTER’ 401 | #define GetOpenFile RB_IO_POINTER | ^~~~~~~~~~~~~ my_fileno.h:30:2: note: in expansion of macro ‘GetOpenFile’ 30 | GetOpenFile(io, fptr); | ^~~~~~~~~~~ /workspaces/project/vendor/ruby/30c1fc4087744da4dcc1138e23cf43118e10f5af/include/ruby-3.3.0+0/ruby/io.h:638:34: note: expected ‘rb_io_t *’ {aka ‘struct rb_io *’} but argument is of type ‘int *’ 638 | void rb_io_check_closed(rb_io_t *fptr); | ~~~~~~~~~^~~~ In file included from accept.c:7: my_fileno.h:17:41: error: request for member ‘f’ in something not a structure or union 17 | # define FPTR_TO_FD(fptr) fileno(fptr->f) | ^~ my_fileno.h:31:7: note: in expansion of macro ‘FPTR_TO_FD’ 31 | fd = FPTR_TO_FD(fptr); | ^~~~~~~~~~ accept.c: At top level: cc1: note: unrecognized command-line option ‘-Wno-self-assign’ may have been intended to silence earlier diagnostics cc1: note: unrecognized command-line option ‘-Wno-parentheses-equality’ may have been intended to silence earlier diagnostics cc1: note: unrecognized command-line option ‘-Wno-constant-logical-operand’ may have been intended to silence earlier diagnostics make: *** [Makefile:248: accept.o] Error 1 make failed, exit code 2 ``` }} ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-103675 * Author: ioquatix (Samuel Williams) * Status: Assigned * Priority: Normal * Assignee: ioquatix (Samuel Williams) ---------------------------------------- In order to make improvements to the IO implementation like <https://bugs.ruby-lang.org/issues/18455>, we need to add new fields to `struct rb_io_t`. By the way, ending types in `_t` is not recommended by POSIX, so I'm also trying to rename the internal implementation to drop `_t` where possible during this conversion. Anyway, we should try to hide the implementation of `struct rb_io`. Ideally, we don't expose any of it, but the problem is backwards compatibility. So, in order to remain backwards compatibility, we should expose some fields of `struct rb_io`, the most commonly used one is `fd` and `mode`, but several others are commonly used. There are many fields which should not be exposed because they are implementation details. ## Current proposal The current proposed change <https://github.com/ruby/ruby/pull/6511> creates two structs: ```c // include/ruby/io.h #ifndef RB_IO_T struct rb_io { int fd; // ... public fields ... }; #else struct rb_io; #endif // internal/io.h #define RB_IO_T struct rb_io { int fd; // ... public fields ... // ... private fields ... }; ``` However, we are not 100% confident this is safe according to the C specification. My experience is not sufficiently wide to say this is safe in practice, but it does look okay to both myself, and @Eregon + @tenderlovemaking have both given some kind of approval. That being said, maybe it's not safe. There are two alternatives: ## Hide all details We can make public `struct rb_io` completely invisible. ```c // include/ruby/io.h #define RB_IO_HIDDEN struct rb_io; int rb_ioptr_descriptor(struct rb_io *ioptr); // accessor for previously visible state. // internal/io.h struct rb_io { // ... all fields ... }; ``` This would only be forwards compatible, and code would need to feature detect like this: ```c #ifdef RB_IO_HIDDEN #define RB_IOPTR_DESCRIPTOR rb_ioptr_descriptor #else #define RB_IOPTR_DESCRIPTOR(ioptr) rb_ioptr_descriptor(ioptr) #endif ``` ## Nested public interface Alternatively, we can nest the public fields into the private struct: ```c // include/ruby/io.h struct rb_io_public { int fd; // ... public fields ... }; // internal/io.h #define RB_IO_T struct rb_io { struct rb_io_public public; // ... private fields ... }; ``` ## Considerations I personally think the "Hide all details" implementation is the best, but it's also the lest compatible. This is also what we are ultimately aiming for, whether we decide to take an intermediate "compatibility step" is up to us. I think "Nested public interface" is messy and introduces more complexity, but it might be slightly better defined than the "Current proposal" which might create undefined behaviour. That being said, all the tests are passing. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114013] [Ruby master Bug#18810] Make `Kernel#p` interruptable.
by Eregon (Benoit Daloze) 23 Jun '23

23 Jun '23

Issue #18810 has been updated by Eregon (Benoit Daloze). It's because the code changed on master, https://github.com/ruby/ruby/commit/fe6b2e20e9f17ed2c2900aa72994e075ffdc7124 had that bug but master doesn't call `inspect` under `rb_uninterruptible()`. On master: ```c static VALUE rb_f_p(int argc, VALUE *argv, VALUE self) { int i; for (i=0; i<argc; i++) { VALUE inspected = rb_obj_as_string(rb_inspect(argv[i])); rb_uninterruptible(rb_p_write, inspected); } return rb_p_result(argc, argv); } static VALUE rb_p_result(int argc, const VALUE *argv) { VALUE ret = Qnil; if (argc == 1) { ret = argv[0]; } else if (argc > 1) { ret = rb_ary_new4(argc, argv); } VALUE r_stdout = rb_ractor_stdout(); if (RB_TYPE_P(r_stdout, T_FILE)) { rb_uninterruptible(rb_io_flush, r_stdout); } return ret; } ``` So only the write and the flush are uninterruptible now. So it does not seem correct to say `Kernel#p is uninterruptible`. These rb_uninterruptible() seem to have very little effect, indeed it's only if there was a `Thread.handle_interrupt(TimeoutError => :on_blocking)` around the `p` and there is an interrupt and STDOUT is not just a TTY or a file where `write` cannot be interrupted anyway IIRC, then it could happen the interrupt is done during `p`'s `write` (or flush), instead of another blocking call in that block. I think that's fully expected, we are trying to tweak a corner of a very rare case by making things complicated, it seems not worth it. ---------------------------------------- Bug #18810: Make `Kernel#p` interruptable. https://bugs.ruby-lang.org/issues/18810#change-103674 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- While figuring out https://bugs.ruby-lang.org/issues/18465 I found a test which fails when `rb_io_flush` becomes blocking.: https://github.com/ruby/ruby/commit/fe6b2e20e9f17ed2c2900aa72994e075ffdc7124 It seems unusual to me that `Kernel#p` is uninterruptible (unique among all Ruby methods). I'd like to make `Kernel#p` interruptible. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114012] [Ruby master Bug#18810] Make `Kernel#p` interruptable.
by Eregon (Benoit Daloze) 23 Jun '23

23 Jun '23

Issue #18810 has been updated by Eregon (Benoit Daloze). Mmh, but it does work to interrupt `p`: ``` $ ruby -e 'o=Object.new; def o.inspect; loop { Thread.pass }; end; p 1; p o' 1 ^C-e:1:in `pass': Interrupt from -e:1:in `block in inspect' from -e:1:in `loop' from -e:1:in `inspect' from -e:1:in `p' from -e:1:in `<main>' ``` What am I missing then? ---------------------------------------- Bug #18810: Make `Kernel#p` interruptable. https://bugs.ruby-lang.org/issues/18810#change-103673 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- While figuring out https://bugs.ruby-lang.org/issues/18465 I found a test which fails when `rb_io_flush` becomes blocking.: https://github.com/ruby/ruby/commit/fe6b2e20e9f17ed2c2900aa72994e075ffdc7124 It seems unusual to me that `Kernel#p` is uninterruptible (unique among all Ruby methods). I'd like to make `Kernel#p` interruptible. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114011] [Ruby master Bug#18810] Make `Kernel#p` interruptable.
by Eregon (Benoit Daloze) 23 Jun '23

23 Jun '23

Issue #18810 has been updated by Eregon (Benoit Daloze). `p` being uninterruptible means all of `object.inspect` and potential Fiber scheduler code is run under `Thread.handle_interrupt(Object => :never) { ... }`. That seems a really bad idea, because e.g. if `inspect` would take a long time (creates a huge String or buggy), then it's not possible to interrupt it, e.g. with Ctrl+C. I think this is a CRuby bug, it's too dangerous to disable interrupts for arbitrary code. ---------------------------------------- Bug #18810: Make `Kernel#p` interruptable. https://bugs.ruby-lang.org/issues/18810#change-103672 * Author: ioquatix (Samuel Williams) * Status: Open * Priority: Normal * Assignee: ioquatix (Samuel Williams) * Backport: 2.7: UNKNOWN, 3.0: UNKNOWN, 3.1: UNKNOWN ---------------------------------------- While figuring out https://bugs.ruby-lang.org/issues/18465 I found a test which fails when `rb_io_flush` becomes blocking.: https://github.com/ruby/ruby/commit/fe6b2e20e9f17ed2c2900aa72994e075ffdc7124 It seems unusual to me that `Kernel#p` is uninterruptible (unique among all Ruby methods). I'd like to make `Kernel#p` interruptible. -- https://bugs.ruby-lang.org/

1 0