Can't set up Ruby 3.4: ruby_executable_node() gave node_status 0 exit status 1

[Jomy10]

The following code produces my error:

import RubyGateway

try Ruby.eval("puts 'test'")

Error returned:

/Users/jonaseveraert/.rubies/3.4.1/lib/ruby/3.4.0/arm64-darwin24/rbconfig.rb:303:in 'String#gsub': cannot set encoding on non-encoding capable object (ArgumentError)
	from /Users/jonaseveraert/.rubies/3.4.1/lib/ruby/3.4.0/arm64-darwin24/rbconfig.rb:303:in 'RbConfig.expand'
	from /Users/jonaseveraert/.rubies/3.4.1/lib/ruby/3.4.0/arm64-darwin24/rbconfig.rb:321:in 'block in <module:RbConfig>'
	from /Users/jonaseveraert/.rubies/3.4.1/lib/ruby/3.4.0/arm64-darwin24/rbconfig.rb:320:in 'Hash#each_value'
	from /Users/jonaseveraert/.rubies/3.4.1/lib/ruby/3.4.0/arm64-darwin24/rbconfig.rb:320:in '<module:RbConfig>'
	from /Users/jonaseveraert/.rubies/3.4.1/lib/ruby/3.4.0/arm64-darwin24/rbconfig.rb:11:in '<top (required)>'
	from /Users/jonaseveraert/.rubies/3.4.1/lib/ruby/3.4.0/rubygems.rb:9:in 'Kernel#require'
	from /Users/jonaseveraert/.rubies/3.4.1/lib/ruby/3.4.0/rubygems.rb:9:in '<top (required)>'
	from <internal:gem_prelude>:2:in 'Kernel#require'
	from <internal:gem_prelude>:2:in '<internal:gem_prelude>'
Swift/ErrorType.swift:253: Fatal error: Error raised at `top level: Can't set up Ruby: ruby_executable_node() gave node_status 0 exit status 1

I configured CRuby with:

Packages/CRuby/cfg-cruby --mode pkgconfig --name 3.4

Ruby version: ruby 3.4.1 (2024-12-25 revision 48d4efcb85) +PRISM [arm64-darwin24]
Swift version:

swift-driver version: 1.115.1 Apple Swift version 6.0.3 (swiftlang-6.0.3.1.10 clang-1600.0.30.1)
Target: arm64-apple-macosx15.0

RubyGateway version: 6.0.0

[Jomy10]

Seems to be an error on ruby version 3.4
Tried with ruby version 3.2, that works without error

[johnfairh]

Thanks - I haven't had a chance to look at this year's Ruby yet, error is right during VM setup I think, hasn't even got to your code. Will take a look.

[johnfairh]

lol rbenv 3.4.1 is differently bad, segfault while trying to BUG I think but doing approx the same require you're seeing.
(intel macos 15.2)

/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(rb_vm_bugreport+0x9bd) [0x1030fc4dd]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(rb_bug_for_fatal_signal+0x148) [0x102f15c08]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(sigsegv+0x4c) [0x10305156c]
/usr/lib/system/libsystem_platform.dylib(_sigtramp+0x1d) [0x7ff8017dae1d]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(rb_id_table_lookup+0x15) [0x103090ac5]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(callable_method_entry_or_negative+0xd8) [0x1030d6f48]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(rb_vm_search_method_slowpath+0xcf) [0x1030c9f2f]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(gccct_method_search_slowpath+0x1c) [0x1030e5f8c]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(rb_funcallv_scope+0x18b) [0x1030db97b]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(rb_funcall+0x190) [0x1030dc020]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(rb_obj_as_string+0x3a) [0x10306b6fa]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(ruby__sfvextra+0xca) [0x103058c6a]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(BSD_vfprintf+0x21f3) [0x103057b83]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(ruby_vsprintf0+0xae) [0x10305565e]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(rb_sprintf+0xbf) [0x1030557ff]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(unexpected_type+0x57) [0x10317b87d]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(rb_unexpected_type+0x23) [0x10317b8ba]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(rb_fstring+0x198) [0x103068678]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(require_internal+0x9ee) [0x102f8447e]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(rb_require_string_internal+0x4f) [0x102f836ef]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(rb_f_require+0x3b) [0x102f835cb]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(vm_call_cfunc_with_frame_+0x134) [0x1030ed8b4]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(vm_exec_core+0x2d70) [0x1030d03e0]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(rb_vm_exec+0x116) [0x1030cc336]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(load_iseq_eval+0x26e) [0x102f8657e]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(require_internal+0xab5) [0x102f84545]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(rb_require_string_internal+0x4f) [0x102f836ef]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(rb_f_require+0x3b) [0x102f835cb]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(vm_call_cfunc_with_frame_+0x134) [0x1030ed8b4]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(vm_exec_core+0x2d70) [0x1030d03e0]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(rb_vm_exec+0x116) [0x1030cc336]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(ruby_opt_init+0x124) [0x103047a24]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(ruby_process_options+0xbea) [0x103045c1a]
/Users/johnf/.rbenv/versions/3.4.1/lib/libruby.3.4.dylib(ruby_options+0x9d) [0x102f209fd]

[johnfairh]

Crashes same from straight C, probably not Swift's fault.

-- Control frame information -----------------------------------------------
c:0005 p:---- s:0024 e:000023 CFUNC  :require
c:0004 p:0005 s:0019 e:000018 TOP    /Users/johnf/.rbenv/versions/3.4.1/lib/ruby/3.4.0/rubygems.rb:9 [FINISH]
c:0003 p:---- s:0012 e:000011 CFUNC  :require
c:0002 p:0012 s:0007 e:000006 TOP    <internal:gem_prelude>:2 [FINISH]
c:0001 p:0000 s:0003 E:0026c0 DUMMY  [FINISH]

e: Linux 3.4.1 breaks in the same way (#52) - not a macOS ruby-build problem. Must be how I'm holding it, sadly.

[Jomy10]

I've set up CRuby with pkcconfig instead of rbenv, I don't seem to get that segfault. (Ruby was installed using ruby-build -d 3.4.1 ~/.rubies

I did take a look look at the source code, seems the error is thrown from here:

RubyGateway/Sources/RubyGateway/RbVM.swift

Line 136 in 9aca654

try RbError.raise(error: .setup("ruby_executable_node() gave node_status \(node_status) exit status \(exit_status)"))

I don't know what ruby_options and ruby_executable_node do exactly.

Using just CRuby I could get a regular example to work e.g.

import CRuby

ruby_init();
rb_eval_string("puts 'hello'");

[johnfairh]

Yes it the ruby_options that's failing, ruby_executable_node just reports the error. I think the reason the ruby_options is there is to set up rubygems properly -- has been a while.

[Jomy10]

Ah that makes sense.

Had a thought that maybe something changed in the C API, but I could only find some functions that were removed in 5.4: https://docs.ruby-lang.org/en/3.4/NEWS_md.html#label-C+API+updates

I'll do some testing later

[johnfairh]

Comparing & experimenting with the actual ruby code, the problem goes away if we call RUBY_INIT_STACK. This didn't used to be necessary because pthread_get_stackaddr_np() meant that we built ruby with MAINSTACKADDR_AVAILABLE and ruby_init_stack() was meaningless. So something has changed in ruby here.

If we're actually obliged to call this thing with a legit value then the API is problematic for RubyGateway because we don't have a 'root' stack frame to tell Ruby about.

Aha, it's ruby/ruby#9505 which removed an init_stack() call from within ruby_setup() that we were previously accidentally taking advantage of.

So.... need to stare at this code all over again and reach certainty that this is still not actually relevant and it's OK to just do what we used to do in Ruby 3.3. It is not a goal of this project to work correctly with "ruby asan fake stacks" whatever they turn out to be.

e: while debugging this I stumbled in a stacksmasher caused by RbException.description calling #class on the exception object and having that call fail -- unclear if related to this thing or not, don't forget to check it.

e2: from the ruby build/configure log:

checking for pthread_attr_setinheritsched... yes
checking for pthread_attr_get_np... no
checking for pthread_attr_getstack... yes
checking for pthread_attr_getguardsize... yes
checking for pthread_get_stackaddr_np... yes
checking for pthread_get_stacksize_np... yes

....so HAVE_PTHREAD_GET_STACKADDR_NP and HAVE_PTHREAD_GET_STACKSIZE_NP therefore STACKADDR_AVAILABLE and MAINSTACKADDR_AVAILABLE. Fine. Nothing super-dramatic has changed.