March 2024 - ruby-core - ml.ruby-lang.org

[ruby-core:117366] [Ruby master Bug#20400] Nested BEGIN{} execution order

by kddnewton (Kevin Newton)

Issue #20400 has been reported by kddnewton (Kevin Newton). ---------------------------------------- Bug #20400: Nested BEGIN{} execution order https://bugs.ruby-lang.org/issues/20400 * Author: kddnewton (Kevin Newton) * Status: Open * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- Right now there are specs for the order in which `BEGIN{}` should be executed, which is the order they appear in the file. For example: ```ruby BEGIN { print "1" } print "4" BEGIN { print "2" } print "5" BEGIN { print "3" } ``` should output "12345". However, I couldn't find any tests/specs on what happens when `BEGIN{}` is nested. The order appears to be somewhat confusing, so I wanted to clarify if it was intentional or a bug. For example: ```ruby BEGIN { print "1" BEGIN { print "2" } } ``` prints "21", and: ```ruby BEGIN { print "1" BEGIN { print "2" } BEGIN { print "3" } } ``` prints "231", and finally: ```ruby BEGIN { print "1" BEGIN { print "2" BEGIN { print "3" } } BEGIN { print "4" } } ``` prints "3241". Is this intentional? -- https://bugs.ruby-lang.org/

1 month, 3 weeks

2
2
0 0

[ruby-core:117354] [Ruby master Bug#20398] heap-buffer-overflow in numeric literal parsing

by kjtsanaktsidis (KJ Tsanaktsidis)

Issue #20398 has been reported by kjtsanaktsidis (KJ Tsanaktsidis). ---------------------------------------- Bug #20398: heap-buffer-overflow in numeric literal parsing https://bugs.ruby-lang.org/issues/20398 * Author: kjtsanaktsidis (KJ Tsanaktsidis) * Status: Open * Assignee: kjtsanaktsidis (KJ Tsanaktsidis) * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I found the following ASAN error in `TestRubyLiteral#test_integer`. It appears that this code is calling strlen on a non-null terminated string. ``` [1/1] TestRubyLiteral#test_integer================================================================= ==484771==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x5060001ab1fc at pc 0x5597fe21d8e1 bp 0x7ffdc6fb0a50 sp 0x7ffdc6fb0210 READ of size 61 at 0x5060001ab1fc thread T0 #0 0x5597fe21d8e0 in strlen.part.0 /home/kj/llvm-project/compiler-rt/lib/asan/../sanitizer_common/sanitizer_common_interceptors.inc:391:5 #1 0x5597fe6b2feb in ruby_strdup /home/kj/ruby/build/../util.c:538:18 #2 0x5597fe4cb1c5 in set_number_literal /home/kj/ruby/build/parse.y:9694:9 #3 0x5597fe4cab3d in no_digits /home/kj/ruby/build/parse.y:10409:12 #4 0x5597fe4b9de9 in parse_numeric /home/kj/ruby/build/parse.y #5 0x5597fe4a8adf in parser_yylex /home/kj/ruby/build/parse.y #6 0x5597fe45c5cd in yylex /home/kj/ruby/build/parse.y:11916:9 #7 0x5597fe45c5cd in ruby_yyparse /home/kj/ruby/build/parse.c:11200:16 #8 0x5597fe49dc00 in yycompile0 /home/kj/ruby/build/parse.y:8121:9 #9 0x5597fe76db1b in rb_suppress_tracing /home/kj/ruby/build/../vm_trace.c:487:18 #10 0x5597fe494416 in yycompile /home/kj/ruby/build/parse.y:8177:5 #11 0x5597fe494416 in parser_compile_string /home/kj/ruby/build/parse.y:8240:12 #12 0x5597fe494416 in rb_ruby_parser_compile_string_path /home/kj/ruby/build/parse.y:8247:12 #13 0x5597fe498858 in rb_parser_compile_string_path /home/kj/ruby/build/parse.y:16663:12 #14 0x5597fe75688c in eval_make_iseq /home/kj/ruby/build/../vm_eval.c:1799:11 #15 0x5597fe70c8fa in eval_string_with_cref /home/kj/ruby/build/../vm_eval.c:1837:12 #16 0x5597fe70c396 in rb_f_eval /home/kj/ruby/build/../vm_eval.c:1912:16 #17 0x5597fe73f5e2 in vm_call_cfunc_with_frame_ /home/kj/ruby/build/../vm_insnhelper.c:3492:11 #18 0x5597fe6dca64 in vm_sendish /home/kj/ruby/build/../vm_callinfo.h #19 0x5597fe6e64fa in vm_exec_core /home/kj/ruby/build/../insns.def:867:11 #20 0x5597fe6dde00 in vm_exec_loop /home/kj/ruby/build/../vm.c:2578:22 #21 0x5597fe6dde00 in rb_vm_exec /home/kj/ruby/build/../vm.c:2557:18 #22 0x5597fe758bc4 in invoke_block /home/kj/ruby/build/../vm.c:1515:12 #23 0x5597fe758bc4 in invoke_iseq_block_from_c /home/kj/ruby/build/../vm.c:1585:16 #24 0x5597fe758bc4 in invoke_block_from_c_bh /home/kj/ruby/build/../vm.c:1603:20 #25 0x5597fe70e4b7 in vm_yield_with_cref /home/kj/ruby/build/../vm.c:1640:12 #26 0x5597fe709861 in vm_yield /home/kj/ruby/build/../vm.c:1648:12 #27 0x5597fe709861 in rb_yield_0 /home/kj/ruby/build/../vm_eval.c:1366:12 #28 0x5597fe709861 in rb_yield /home/kj/ruby/build/../vm_eval.c #29 0x5597fec0eff9 in rb_ary_collect /home/kj/ruby/build/../array.c:3601:30 #30 0x5597fe73f5e2 in vm_call_cfunc_with_frame_ /home/kj/ruby/build/../vm_insnhelper.c:3492:11 #31 0x5597fe6dca64 in vm_sendish /home/kj/ruby/build/../vm_callinfo.h #32 0x5597fe6e2d8f in vm_exec_core /home/kj/ruby/build/../insns.def:847:11 #33 0x5597fe6dde00 in vm_exec_loop /home/kj/ruby/build/../vm.c:2578:22 #34 0x5597fe6dde00 in rb_vm_exec /home/kj/ruby/build/../vm.c:2557:18 #35 0x5597fe3ffe9e in load_iseq_eval /home/kj/ruby/build/../load.c:778:5 #36 0x5597fe3fb498 in require_internal /home/kj/ruby/build/../load.c:1284:21 #37 0x5597fe3f9bf3 in rb_require_string_internal /home/kj/ruby/build/../load.c:1383:18 #38 0x5597fe73f5e2 in vm_call_cfunc_with_frame_ /home/kj/ruby/build/../vm_insnhelper.c:3492:11 #39 0x5597fe6dca64 in vm_sendish /home/kj/ruby/build/../vm_callinfo.h #40 0x5597fe6e64fa in vm_exec_core /home/kj/ruby/build/../insns.def:867:11 #41 0x5597fe6dda82 in rb_vm_exec /home/kj/ruby/build/../vm.c:2551:22 #42 0x5597fe30a753 in rb_ec_exec_node /home/kj/ruby/build/../eval.c:283:9 #43 0x5597fe30a43d in ruby_run_node /home/kj/ruby/build/../eval.c:323:30 #44 0x5597fe3059b0 in rb_main /home/kj/ruby/build/../main.c:40:12 #45 0x5597fe3059b0 in main /home/kj/ruby/build/../main.c:59:12 #46 0x7f1a93141149 in __libc_start_call_main /usr/src/debug/glibc-2.38-16.fc39.x86_64/csu/../sysdeps/nptl/libc_start_call_main.h:58:16 #47 0x7f1a9314120a in __libc_start_main(a)GLIBC_2.2.5 /usr/src/debug/glibc-2.38-16.fc39.x86_64/csu/../csu/libc-start.c:360:3 #48 0x5597fe1d3e34 in _start (/home/kj/ruby/build/ruby+0x38ae34) 0x5060001ab1fc is located 0 bytes after 60-byte region [0x5060001ab1c0,0x5060001ab1fc) allocated by thread T0 here: #0 0x5597fe2bde4f in malloc /home/kj/llvm-project/compiler-rt/lib/asan/asan_malloc_linux.cpp:68:3 #1 0x5597fe3491a9 in objspace_xmalloc0 /home/kj/ruby/build/../gc.c:12605:5 #2 0x5597fe4a8adf in parser_yylex /home/kj/ruby/build/parse.y #3 0x5597fe45c5cd in yylex /home/kj/ruby/build/parse.y:11916:9 #4 0x5597fe45c5cd in ruby_yyparse /home/kj/ruby/build/parse.c:11200:16 #5 0x5597fe49dc00 in yycompile0 /home/kj/ruby/build/parse.y:8121:9 SUMMARY: AddressSanitizer: heap-buffer-overflow /home/kj/ruby/build/../util.c:538:18 in ruby_strdup Shadow bytes around the buggy address: 0x5060001aaf00: fa fa fa fa fd fd fd fd fd fd fd fd fa fa fa fa 0x5060001aaf80: 00 00 00 00 00 00 00 04 fa fa fa fa 00 00 00 00 0x5060001ab000: 00 00 00 fa fa fa fa fa 00 00 00 00 00 00 00 fa 0x5060001ab080: fa fa fa fa 00 00 00 00 00 00 00 00 fa fa fa fa 0x5060001ab100: 00 00 00 00 00 00 00 00 fa fa fa fa 00 00 00 00 =>0x5060001ab180: 00 00 00 00 fa fa fa fa 00 00 00 00 00 00 00[04] 0x5060001ab200: fa fa fa fa fd fd fd fd fd fd fd fd fa fa fa fa 0x5060001ab280: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x5060001ab300: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x5060001ab380: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x5060001ab400: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe Left alloca redzone: ca Right alloca redzone: cb ==484771==ABORTING ``` -- https://bugs.ruby-lang.org/

1 month, 3 weeks

2
3
0 0

[ruby-core:117370] [Ruby master Bug#17996] Cygwin: thread + pipe behavior since Ruby 2.6

by hsbt (Hiroshi SHIBATA)

Issue #17996 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Open to Closed https://github.com/ruby/ruby/pull/9357 may be fixed this. ---------------------------------------- Bug #17996: Cygwin: thread + pipe behavior since Ruby 2.6 https://bugs.ruby-lang.org/issues/17996#change-107528 * Author: xtkoba (Tee KOBAYASHI) * Status: Closed * Assignee: cygwin * ruby -v: ruby 3.1.0dev (2021-06-10T23:31:51Z master 9210f8df7f) [x86_64-cygwin] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- The following one-liner is the repro named `thread-pipe-read-close.rb` the aim of which is essentially the same as that of "IO#close raises an IOError with a clear message" test in `spec/ruby/core/io/close_spec.rb`. ```ruby r, w = IO.pipe; Thread.new{ r.read }; sleep 0.5; r.close ``` Run on Cygwin with Ruby 2.6 or later, this hangs up indefinitely consuming a full core. On the other hand, with Ruby 2.5.9p229 it works as expected. ``` $ miniruby25 -v ruby 2.5.9p229 (2021-04-05 revision 67939) [x86_64-cygwin] $ miniruby25 thread-pipe-read-close.rb #<Thread:0x000000080006c9f0@thread-pipe-read-close.rb:2 run> terminated with exception (report_on_exception is true): Traceback (most recent call last): 1: from thread-pipe-read-close.rb:2:in `block in <main>' thread-pipe-read-close.rb:2:in `read': IOError $ miniruby -v ruby 3.1.0dev (2021-06-10T23:31:51Z master 9210f8df7f) [x86_64-cygwin] $ miniruby thread-pipe-read-close.rb ``` -- https://bugs.ruby-lang.org/

1 month, 3 weeks

1
0
0 0

[ruby-core:117324] [Ruby master Feature#20394] Add an offset parameter to `String#to_i`

by byroot (Jean Boussier)

Issue #20394 has been reported by byroot (Jean Boussier). ---------------------------------------- Feature #20394: Add an offset parameter to `String#to_i` https://bugs.ruby-lang.org/issues/20394 * Author: byroot (Jean Boussier) * Status: Open ---------------------------------------- ### Context I maintain the `redis-client` gem, and it comes with an optional swapable implementation in C that binds the `hiredis` C client, [which used to performs up to 5 times faster in some cases](https://github.com/redis-rb/redis-client/commit/9fabd57c6786a03fe0c6…. I recently paired with @tenderlovemaking to try to close this gap, or even try to make the pure Ruby version faster, and we came up with several optimizations that now almost make both version on par (assuming YJIT is enabled). An important source of performance loss, is that the Redis protocol is line based and to parse it in Ruby requires to slice a lot of small strings from the buffer. To give an example, here's how an Array with two String (`["foo", "plop"]`) is serialized in RESP3 (Redis protocol): ``` *2\r\n $3\r\n foo\r\n $4\r\n plop\r\n ``` From this you can understand that a big hotspot in the parser is essentially `Integer(gets)`. With @tenderlovemaking we managed to get [a fairly significant perf boost](https://github.com/redis-rb/redis-client/commit/41b3abe94243d2598211… by avoiding these string allocation using `String#getbyte` and [basically implementing a rudimentary `String#to_i(offset: )` in Ruby](https://github.com/redis-rb/redis-client/commit/41b3abe94243d2598211d…. But while the gains are huge with YJIT enabled, they are much more tame with the interpreter. And it feels a bit wrong to have to implement this sorts of things for performance reasons. ### `String#to_i(offset: )` Similar to `String#unpack(offset:)` ([Feature #18254]), I believe `String#to_i(offset: )` would be useful. ### Alternative new `String#unpack` format Another possibility would be to add a new format to `String#pack` `String#unpack` for decimal numbers. It sounds a bit weird at first, but given it supports things like Base64 and hexadecimal, perhaps it's not that much of a stretch? -- https://bugs.ruby-lang.org/

1 month, 3 weeks

7
15
0 0

[ruby-core:117300] [Ruby master Feature#19057] Hide implementation of `rb_io_t`.

by ioquatix (Samuel Williams)

Issue #19057 has been updated by ioquatix (Samuel Williams). > Why don't you reconsider the "nested public interface" approach? My assessment of this approach is that it would require a rewrite of all internal code that accesses `rb_io_t` internals. Rewriting code isn't a problem, but it takes a lot of time and effort that I don't have in abundance right now. Additionally, it's still only a partial solution. One of the issues is accessing the file descriptor directly and the handling of `IO#close` from a different thread/fiber. Using the file descriptor directly can be problematic. > Ruby lost numerous users due to a never-ending stream of incompatibilities introduced every year. Compatibility and progress are always something to balance out. I think on the whole, Ruby does a pretty decent job at it. Lack of forward progress also causes users to look elsewhere as the language stagnates. So this isn't just. a matter of "preserve compatibility at all costs", as those costs will be the same. The hard part is finding the middle ground of compatibility and progress. Both compatibility at any cost, and progress at any cost, are naive statements. ---------------------------------------- Feature #19057: Hide implementation of `rb_io_t`. https://bugs.ruby-lang.org/issues/19057#change-107442 * Author: ioquatix (Samuel Williams) * Status: Assigned * Assignee: ioquatix (Samuel Williams) * Target version: 3.4 ---------------------------------------- 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 month, 3 weeks

2
1
0 0

[ruby-core:117351] embedd ruby 3.3.0 - unknown Time.now class method

by fiesta06

Hi, I want to embedd the ruby 3.3.0 interpreter into my application by using the following code: int error, n; static char* args[] = {}; n = 0; ruby_sysinit(&n, (char ***)&args); RUBY_INIT_STACK; ruby_init(); ruby_init_loadpath(); rb_eval_string_protect("p Time.now", &error); if(error) { rb_eval_string("p :ERROR"); } In principle it does work. However, the Time class is missing the now method, thus a :ERROR is printed. What it missing in the above code ?

1 month, 3 weeks

1
0
0 0

[ruby-core:117326] [Ruby master Bug#20395] Invalid license note in vsnprintf.c

by vo.x (Vit Ondruch)

Issue #20395 has been reported by vo.x (Vit Ondruch). ---------------------------------------- Bug #20395: Invalid license note in vsnprintf.c https://bugs.ruby-lang.org/issues/20395 * Author: vo.x (Vit Ondruch) * Status: Open * ruby -v: ruby 3.3.0 (2023-12-25 revision 5124f9ac75) [x86_64-linux] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN, 3.3: UNKNOWN ---------------------------------------- I am looking into Ruby licenses and I stumble upon vsnprintf.c, namely about these lines: ~~~ /* * IMPORTANT NOTE: * -------------- * From ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change * paragraph 3 above is now null and void. */ ~~~ I doubt the note is valid since commit:git|626f1ee196fe06514d66771ff0e3f82d7686af25, which actually removes the 3rd clause, while the (broken) URL refers to "4bsd". Can somebody please review? The note from the URL can be likely viewed e.g. [here](https://www.freebsd.org/copyright/license/) -- https://bugs.ruby-lang.org/

1 month, 3 weeks

2
4
0 0

[ruby-core:113782] [Ruby master Bug#19716] SystemStackError occurs too easily on Alpine Linux (due to small stack size reported by pthread_attr_getstacksize on musl libc)

by alexdowad (Alex Dowad)

Issue #19716 has been reported by alexdowad (Alex Dowad). ---------------------------------------- Bug #19716: SystemStackError occurs too easily on Alpine Linux (due to small stack size reported by pthread_attr_getstacksize on musl libc) https://bugs.ruby-lang.org/issues/19716 * Author: alexdowad (Alex Dowad) * Status: Open * Priority: Normal * ruby -v: ruby 3.1.4p223 (2023-03-30 revision 957bb7cb81) [x86_64-linux-musl] * Backport: 3.0: UNKNOWN, 3.1: UNKNOWN, 3.2: UNKNOWN ---------------------------------------- This is the same problem previously reported against Ruby 2.5 in https://bugs.ruby-lang.org/issues/14387. I just ran into the same problem on Ruby 3.1.4, built on Alpine Linux 3.16. @hsbt stated in the previous thread (https://bugs.ruby-lang.org/issues/14387#note-28): > If you have this issue with Ruby 3.2, please file it with another issue. I hacked `stack_check` in gc.c to print the values of `STACK_START` and `STACK_END` on stack overflow; on the Alpine 3.16 host where this problem just occurred, the values printed were: > Start=0x7ffd0bf4f000, End=0x7ffd0bf32530 ...which shows that Ruby thinks the stack size is only 131072 bytes. On the other hand, `ulimit -s` shows a stack size limit of 8192kb. This Ruby 3.1.4 was built from unmodified source code downloaded from https://cache.ruby-lang.org; the build was configured using `CFLAGS='-march=native' ./configure --disable-install-doc`. The invocation of Ruby which blew the stack was `bundle exec rake db:migrate`, on a mid-sized Rails project. Regarding @ncopa's patch from #14387, @wanabe listed some things which should be done before it is merged into mainline Ruby: > Okay, The patch needs one or more proofs of its behaviour, like that: > > Original issue [ruby-dev:50421] has gone away. > Standard test codes run well. > test-all > ruby/spec > getrlimit works on some situations like: > on single thread > with multiple threads > with RLIMIT_STACK environment variable > getrlimit code of musl is implemented correctly as expected. > (But It's doubtful whether it can be. I guess that a proof of code soundness is very difficult.) > Some "real world" applications can work. > I think it is better example that that application(s) can't work without the patch. I am happy to help cover some of these points if the Ruby development team is still interested in merging @ncopa's patch. -- https://bugs.ruby-lang.org/

1 month, 3 weeks

4
5
0 0

[ruby-core:115538] [Ruby master Misc#20028] I'd like my commit bit back

by zenspider (Ryan Davis)

Issue #20028 has been reported by zenspider (Ryan Davis). ---------------------------------------- Misc #20028: I'd like my commit bit back https://bugs.ruby-lang.org/issues/20028 * Author: zenspider (Ryan Davis) * Status: Open * Priority: Normal ---------------------------------------- It's been a while, in the svn -> git shuffle I lost commit privs. I'd like to help out more actively, triage issues, clean doco, etc. Not sure who's doing admin work so I'm not sure who to assign to to expedite. -- https://bugs.ruby-lang.org/

1 month, 3 weeks

4
6
0 0

[ruby-core:117337] [Ruby master Misc#17174] "Error relocating, symbol not found" error when compiling a native extension on Alpine with Ruby >=2.4

by hsbt (Hiroshi SHIBATA)

Issue #17174 has been updated by hsbt (Hiroshi SHIBATA). Status changed from Open to Closed Unfortunately, there is no active maintainer for musl or alpine platform. I tagged them to [musl](https://bugs.ruby-lang.org/projects/ruby-master/issues?fields%5B%5D=i…. We welcome patch for them. ---------------------------------------- Misc #17174: "Error relocating, symbol not found" error when compiling a native extension on Alpine with Ruby >=2.4 https://bugs.ruby-lang.org/issues/17174#change-107491 * Author: Nakilon (Victor Maslov) * Status: Closed ---------------------------------------- My native extension gem compiles fine with all versions of Ruby on macOS but only with Ruby 2.3 on Alpine. It throws various `Error relocating`, `symbol not found` when I require the `.o` file. Here I made a branch to reproduce it in Docker quickly. ``` git clone https://github.com/Nakilon/dhash-vips.git --branch alpine-compilation-issues alpine-compilation-issues && cd alpine-compilation-issues ``` ``` # compiles and does not fail on require docker build - -t temp-ruby2.3.8 --build-arg RUBY_VERSION=2.3.8 --build-arg ALPINE_VERSION=3.8 <Dockerfile # Error relocating /dhash-vips/idhash.so: rb_deprecate_constant: symbol not found - /dhash-vips/idhash.so (LoadError) docker build - -t temp-ruby2.4.10 --build-arg RUBY_VERSION=2.4.10 --build-arg ALPINE_VERSION=3.11 <Dockerfile # Error relocating /dhash-vips/idhash.so: rb_int_modulo: symbol not found - /dhash-vips/idhash.so (LoadError) docker build - -t temp-ruby2.5.8 --build-arg RUBY_VERSION=2.5.8 --build-arg ALPINE_VERSION=3.12 <Dockerfile # Error relocating /dhash-vips/idhash.so: rb_int_pow: symbol not found - /dhash-vips/idhash.so (LoadError) docker build - -t temp-ruby2.6.6 --build-arg RUBY_VERSION=2.6.6 --build-arg ALPINE_VERSION=3.12 <Dockerfile ``` I wanted to ask in the Mailing List but for some reason my email didn't reach it. Guy on Freenode recommended to post here. -- https://bugs.ruby-lang.org/

1 month, 3 weeks

1
0
0 0

2024

2023

2022

ruby-core March 2024