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

[ruby-core:114474] [Ruby master Bug#16492] TestBugReporter#test_bug_reporter_add test failures
by jeremyevans0 (Jeremy Evans) 23 Aug '23

23 Aug '23

Issue #16492 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed I checked all recent ruby-master failures in the RHEL 7.1 s390 CI (http://rubyci.s3.amazonaws.com/rhel_zlinux/ruby-master/recent.html) and none show this issue. Considering this error was occuring in 90% of cases, since it hasn't happened recently, I assume this has been fixed. If you are still seeing this error with current Ruby, please reply and we can reopen. ---------------------------------------- Bug #16492: TestBugReporter#test_bug_reporter_add test failures https://bugs.ruby-lang.org/issues/16492#change-104257 * Author: vo.x (Vit Ondruch) * Status: Closed * Priority: Normal * Assignee: jaruga (Jun Aruga) * ruby -v: ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [s390x-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN ---------------------------------------- Building Ruby packages on Fedora, in 90% of cases, I observe the following error on s390: ~~~ 1) Error: TestBugReporter#test_bug_reporter_add: Timeout::Error: execution of assert_in_out_err expired timeout (10 sec) pid 2061293 killed by SIGKILL (signal 9) | | -:1: [BUG] Segmentation fault at 0x001f73ed000003e8 | ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [s390x-linux] | | -- Control frame information ----------------------------------------------- | c:0003 p:---- s:0012 e:000011 CFUNC :kill | c:0002 p:0021 s:0006 e:000005 EVAL -:1 [FINISH] | c:0001 p:0000 s:0003 E:000430 (none) [FINISH] | | -- Ruby level backtrace information ---------------------------------------- | -:1:in `<main>' | -:1:in `kill' | | -- Other runtime information ----------------------------------------------- | | * Loaded script: - | | * Loaded features: | | 0 enumerator.so | 1 thread.rb | 2 rational.so | 3 complex.so | 4 ruby2_keywords.rb | 5 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/enc/encdb.so | 6 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/enc/trans/transdb.so | 7 /builddir/build/BUILD/ruby-2.7.0/abrt.rb | 8 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/-test-/bug_reporter.so | | * Process memory map: | | 2aa27a00000-2aa27a01000 r-xp 00000000 fc:03 1845127 /builddir/build/BUILD/ruby-2.7.0/ruby | 2aa27a01000-2aa27a02000 r--p 00000000 fc:03 1845127 /builddir/build/BUILD/ruby-2.7.0/ruby | 2aa27a02000-2aa27a03000 rw-p 00001000 fc:03 1845127 /builddir/build/BUILD/ruby-2.7.0/ruby | 2aa28a7e000-2aa28bfe000 rw-p 00000000 00:00 0 [heap] | 3ff9ff80000-3ff9ff81000 r-xp 00000000 fc:03 1844756 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/-test-/bug_reporter.so | 3ff9ff81000-3ff9ff82000 r--p 00000000 fc:03 1844756 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/-test-/bug_reporter.so | 3ff9ff82000-3ff9ff83000 rw-p 00000000 00:00 0 | 3ffa0000000-3ffa0002000 r-xp 00000000 fc:03 1844387 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/enc/trans/transdb.so | 3ffa0002000-3ffa0003000 r--p 00001000 fc:03 1844387 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/enc/trans/transdb.so | 3ffa0003000-3ffa0004000 rw-p 00000000 00:00 0 | 3ffa0036000-3ffa0037000 ---p 00000000 00:00 0 | 3ffa0037000-3ffa0078000 rw-p 00000000 00:00 0 | 3ffa0078000-3ffa0079000 ---p 00000000 00:00 0 | 3ffa0079000-3ffa00ba000 rw-p 00000000 00:00 0 | 3ffa00ba000-3ffa00bb000 ---p 00000000 00:00 0 | 3ffa00bb000-3ffa00fc000 rw-p 00000000 00:00 0 | 3ffa00fc000-3ffa00fd000 ---p 00000000 00:00 0 | 3ffa00fd000-3ffa013e000 rw-p 00000000 00:00 0 | 3ffa013e000-3ffa013f000 ---p 00000000 00:00 0 | 3ffa013f000-3ffa0180000 rw-p 00000000 00:00 0 | 3ffa0180000-3ffa0181000 ---p 00000000 00:00 0 | 3ffa0181000-3ffa01c2000 rw-p 00000000 00:00 0 | 3ffa01c2000-3ffa01c3000 ---p 00000000 00:00 0 | 3ffa01c3000-3ffa0204000 rw-p 00000000 00:00 0 | 3ffa0204000-3ffa0205000 ---p 00000000 00:00 0 | 3ffa0205000-3ffa0246000 rw-p 00000000 00:00 0 | 3ffa0246000-3ffa0247000 ---p 00000000 00:00 0 | 3ffa0247000-3ffa0288000 rw-p 00000000 00:00 0 | 3ffa0288000-3ffa0289000 ---p 00000000 00:00 0 | 3ffa0289000-3ffa02ca000 rw-p 00000000 00:00 0 | 3ffa02ca000-3ffa02cb000 ---p 00000000 00:00 0 | 3ffa02cb000-3ffa030c000 rw-p 00000000 00:00 0 | 3ffa030c000-3ffa030d000 ---p 00000000 00:00 0 | 3ffa030d000-3ffa034e000 rw-p 00000000 00:00 0 | 3ffa034e000-3ffa034f000 ---p 00000000 00:00 0 | 3ffa034f000-3ffa0390000 rw-p 00000000 00:00 0 | 3ffa0390000-3ffa0391000 ---p 00000000 00:00 0 | 3ffa0391000-3ffa03d2000 rw-p 00000000 00:00 0 | 3ffa03d2000-3ffa03d3000 ---p 00000000 00:00 0 | 3ffa03d3000-3ffa0414000 rw-p 00000000 00:00 0 | 3ffa0414000-3ffa0415000 ---p 00000000 00:00 0 | 3ffa0415000-3ffa0456000 rw-p 00000000 00:00 0 | 3ffa0456000-3ffa0457000 ---p 00000000 00:00 0 | 3ffa0457000-3ffa0498000 rw-p 00000000 00:00 0 | 3ffa0498000-3ffa0499000 ---p 00000000 00:00 0 | 3ffa0499000-3ffa04da000 rw-p 00000000 00:00 0 | 3ffa04da000-3ffa04db000 ---p 00000000 00:00 0 | 3ffa04db000-3ffa051c000 rw-p 00000000 00:00 0 | 3ffa051c000-3ffa051d000 ---p 00000000 00:00 0 | 3ffa051d000-3ffa055e000 rw-p 00000000 00:00 0 | 3ffa055e000-3ffa055f000 ---p 00000000 00:00 0 | 3ffa055f000-3ffa05a0000 rw-p 00000000 00:00 0 | 3ffa05a0000-3ffa05a1000 ---p 00000000 00:00 0 | 3ffa05a1000-3ffa05e2000 rw-p 00000000 00:00 0 | 3ffa05e2000-3ffa05e3000 ---p 00000000 00:00 0 | 3ffa05e3000-3ffa0624000 rw-p 00000000 00:00 0 | 3ffa0624000-3ffa0625000 ---p 00000000 00:00 0 | 3ffa0625000-3ffa0666000 rw-p 00000000 00:00 0 | 3ffa0666000-3ffa0667000 ---p 00000000 00:00 0 | 3ffa0667000-3ffa06a8000 rw-p 00000000 00:00 0 | 3ffa06a8000-3ffa06a9000 ---p 00000000 00:00 0 | 3ffa06a9000-3ffa06ea000 rw-p 00000000 00:00 0 | 3ffa06ea000-3ffa06eb000 ---p 00000000 00:00 0 | 3ffa06eb000-3ffa072c000 rw-p 00000000 00:00 0 | 3ffa072c000-3ffa072d000 ---p 00000000 00:00 0 | 3ffa072d000-3ffa076e000 rw-p 00000000 00:00 0 | 3ffa076e000-3ffa076f000 ---p 00000000 00:00 0 | 3ffa076f000-3ffa07b0000 rw-p 00000000 00:00 0 | 3ffa07b0000-3ffa07b1000 ---p 00000000 00:00 0 | 3ffa07b1000-3ffa07f2000 rw-p 00000000 00:00 0 | 3ffa07f2000-3ffa07f3000 ---p 00000000 00:00 0 | 3ffa07f3000-3ffa0834000 rw-p 00000000 00:00 0 | 3ffa0834000-3ffa0835000 ---p 00000000 00:00 0 | 3ffa0835000-3ffa2980000 rw-p 00000000 00:00 0 | 3ffa2980000-3ffa2a17000 r-xp 00000000 fc:03 1813828 /usr/lib64/libm-2.30.9000.so | 3ffa2a17000-3ffa2a18000 r--p 00096000 fc:03 1813828 /usr/lib64/libm-2.30.9000.so | 3ffa2a18000-3ffa2a19000 rw-p 00097000 fc:03 1813828 /usr/lib64/libm-2.30.9000.so | 3ffa2a80000-3ffa2ab2000 r-xp 00000000 fc:03 1814596 /usr/lib64/libcrypt.so.2.0.0 | 3ffa2ab2000-3ffa2ab3000 ---p 00032000 fc:03 1814596 /usr/lib64/libcrypt.so.2.0.0 | 3ffa2ab3000-3ffa2ab4000 r--p 00032000 fc:03 1814596 /usr/lib64/libcrypt.so.2.0.0 | 3ffa2ab4000-3ffa2abd000 rw-p 00000000 00:00 0 | 3ffa2b00000-3ffa2b03000 r-xp 00000000 fc:03 1813826 /usr/lib64/libdl-2.30.9000.so | 3ffa2b03000-3ffa2b04000 r--p 00002000 fc:03 1813826 /usr/lib64/libdl-2.30.9000.so | 3ffa2b04000-3ffa2b05000 rw-p 00000000 00:00 0 | 3ffa2b80000-3ffa2c05000 r-xp 00000000 fc:03 1814658 /usr/lib64/libgmp.so.10.3.2 | 3ffa2c05000-3ffa2c07000 r--p 00084000 fc:03 1814658 /usr/lib64/libgmp.so.10.3.2 | 3ffa2c07000-3ffa2c08000 rw-p 00086000 fc:03 1814658 /usr/lib64/libgmp.so.10.3.2 | 3ffa2c80000-3ffa2c88000 r-xp 00000000 fc:03 1813840 /usr/lib64/librt-2.30.9000.so | 3ffa2c88000-3ffa2c89000 r--p 00007000 fc:03 1813840 /usr/lib64/librt-2.30.9000.so | 3ffa2c89000-3ffa2c8a000 rw-p 00008000 fc:03 1813840 /usr/lib64/librt-2.30.9000.so | 3ffa2d00000-3ffa2d1e000 r-xp 00000000 fc:03 1813836 /usr/lib64/libpthread-2.30.9000.so | 3ffa2d1e000-3ffa2d1f000 r--p 0001d000 fc:03 1813836 /usr/lib64/libpthread-2.30.9000.so | 3ffa2d1f000-3ffa2d20000 rw-p 0001e000 fc:03 1813836 /usr/lib64/libpthread-2.30.9000.so | 3ffa2d20000-3ffa2d24000 rw-p 00000000 00:00 0 | 3ffa2d80000-3ffa2f1e000 r-xp 00000000 fc:03 1813824 /usr/lib64/libc-2.30.9000.so | 3ffa2f1e000-3ffa2f22000 r--p 0019d000 fc:03 1813824 /usr/lib64/libc-2.30.9000.so | 3ffa2f22000-3ffa2f25000 rw-p 001a1000 fc:03 1813824 /usr/lib64/libc-2.30.9000.so | 3ffa2f25000-3ffa2f28000 rw-p 00000000 00:00 0 | 3ffa2f80000-3ffa2f82000 r-xp 00000000 fc:03 1844333 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/enc/encdb.so | 3ffa2f82000-3ffa2f83000 r--p 00001000 fc:03 1844333 /builddir/build/BUILD/ruby-2.7.0/.ext/s390x-linux/enc/encdb.so | 3ffa2f83000-3ffa2f84000 rw-p 00000000 00:00 0 | 3ffa3000000-3ffa336e000 r-xp 00000000 fc:03 1844256 /builddir/build/BUILD/ruby-2.7.0/libruby.so.2.7.0 | 3ffa336e000-3ffa3377000 r--p 0036d000 fc:03 1844256 /builddir/build/BUILD/ruby-2.7.0/libruby.so.2.7.0 | 3ffa3377000-3ffa3378000 rw-p 00376000 fc:03 1844256 /builddir/build/BUILD/ruby-2.7.0/libruby.so.2.7.0 | 3ffa3378000-3ffa338f000 rw-p 00000000 00:00 0 | 3ffa3400000-3ffa3426000 r-xp 00000000 fc:03 1813817 /usr/lib64/ld-2.30.9000.so | 3ffa3426000-3ffa3427000 r--p 00025000 fc:03 1813817 /usr/lib64/ld-2.30.9000.so | 3ffa3427000-3ffa3428000 rw-p 00026000 fc:03 1813817 /usr/lib64/ld-2.30.9000.so | 3ffa3428000-3ffa3429000 rw-p 00000000 00:00 0 | 3ffa3476000-3ffa347e000 rw-p 00000000 00:00 0 | 3ffa347e000-3ffa3480000 r-xp 00000000 00:00 0 [vdso] | 3ffc5301000-3ffc5b00000 rw-p 00000000 00:00 0 [stack] | | | Sample bug reporter: 12345 /builddir/build/BUILD/ruby-2.7.0/test/-ext-/bug_reporter/test_bug_reporter.rb:22:in `test_bug_reporter_add' Finished tests in 544.051367s, 38.5515 tests/s, 4998.1953 assertions/s. 20974 tests, 2719275 assertions, 0 failures, 1 errors, 68 skips ruby -v: ruby 2.7.0p0 (2019-12-25 revision 647ee6f091) [s390x-linux] ~~~ Since the default timeout is 10s, I tried to increase the timeout to 30s via simple `sed -i '/assert_in_out_err/ s/)/, timeout: 30)/' test/-ext-/bug_reporter/test_bug_reporter.rb` and this seems to help to avoid this issue. However, I am not really sure why s390x is so slow handling this test case :/ ---Files-------------------------------- 0001-Timeout-the-test_bug_reporter_add-witout-raising-err.patch (1.45 KB) Time.png (56 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114473] [Ruby master Bug#14480] miniruby crashing when compiled with -O2 or -O1 on aarch64
by jeremyevans0 (Jeremy Evans) 23 Aug '23

23 Aug '23

Issue #14480 has been updated by jeremyevans0 (Jeremy Evans). I submitted a pull request to disable `__builtin_setjmp` for Linux aarch64: https://github.com/ruby/ruby/pull/8272 ---------------------------------------- Bug #14480: miniruby crashing when compiled with -O2 or -O1 on aarch64 https://bugs.ruby-lang.org/issues/14480#change-104256 * Author: vo.x (Vit Ondruch) * Status: Open * Priority: Normal * ruby -v: ruby 2.5.0p0 (2017-12-25 revision 61468) [aarch64-linux] * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- Recently, it is not possible to build Ruby 2.5.0 on aarch64 on Fedora Rawhide, because miniruby fails during build: ~~~ ... snip ... ./miniruby -I./lib -I. -I.ext/common -n \ -e 'BEGIN{version=ARGV.shift;mis=ARGV.dup}' \ -e 'END{abort "UNICODE version mismatch: #{mis}" unless mis.empty?}' \ -e '(mis.delete(ARGF.path); ARGF.close) if /ONIG_UNICODE_VERSION_STRING +"#{Regexp.quote(version)}"/o' \ 10.0.0 ./enc/unicode/10.0.0/casefold.h ./enc/unicode/10.0.0/name2ctype.h generating encdb.h ./miniruby -I./lib -I. -I.ext/common ./tool/generic_erb.rb -c -o encdb.h ./template/encdb.h.tmpl ./enc enc generating prelude.c ./miniruby -I./lib -I. -I.ext/common ./tool/generic_erb.rb -I. -c -o prelude.c \ ./template/prelude.c.tmpl ./prelude.rb ./gem_prelude.rb ./abrt_prelude.rb *** stack smashing detected ***: <unknown> terminated encdb.h updated ... snip ... ~~~ This might by Ruby or gcc issue. Not sure yet. However, there is already lengthy analysis available in Fedora's Bugzilla [1]. Would be anybody able to help to resolve this issue? [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1545239 ---Files-------------------------------- Dockerfile (573 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114472] [Ruby master Bug#16288] Segmentation fault with finalizers, threads
by jeremyevans0 (Jeremy Evans) 23 Aug '23

23 Aug '23

Issue #16288 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed davidw (David Welton) wrote in #note-7: > ``` > --- a/thread.c > +++ b/thread.c > @@ -682,7 +682,7 @@ thread_do_start(rb_thread_t *th) > else { > args_ptr = RARRAY_CONST_PTR(args); > } > - > + rb_funcallv(NULL, idInspect, 0, 0); > th->value = rb_vm_invoke_proc(th->ec, proc, > (int)args_len, args_ptr, > VM_BLOCK_HANDLER_NONE); > ``` > > > I replaced the funcall with > > RUBY_VM_CHECK_INTS(GET_EC()); > > And everything seems to work ok. I checked and now we have `vm_check_ints_blocking(th->ec);` in that spot, so I think this is fixed. ---------------------------------------- Bug #16288: Segmentation fault with finalizers, threads https://bugs.ruby-lang.org/issues/16288#change-104255 * Author: davidw (David Welton) * Status: Closed * Priority: Normal * ruby -v: ruby 2.6.6p116 (2019-10-02 revision 67825) [x86_64-linux] * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- Hi, This is a tricky one and I am still working on narrowing it down, but I will report what I have so far. I compiled a version of 2_6_6 from github: ruby 2.6.6p116 (2019-10-02 revision 67825) [x86_64-linux] I have a minimal Rails project that uses Mongoid. It crashes with a segmentation fault when rspec runs. The concurrent ruby gem is in some way involved, and I have been posting there: https://github.com/ruby-concurrency/concurrent-ruby/issues/808 However, I think there is a deeper problem - I would not expect a user level script to cause a segmentation fault. I have been putting a lot of debugging statements in, and turned on Thread.DEBUG, and have noticed some things. I am not experienced with Ruby's internals, so some of these bits of data might be normal or irrelevant: * The concurrent-ruby gem uses ObjectSpace.define_finalizer to set a finalizer * That finalizer creates a new Thread * However, it appears as if that thread is running after the main thread is already dead, so code that expects to reference the main thread crashes, because it's a NULL reference. I tried the following test code: ``` class Foo def initialize ObjectSpace.define_finalizer(self, proc do Foo.foo_finalizer end) end def bar puts 'bar' end def Foo.foo_finalizer puts "foo_finalizer" t = Thread.new do puts "Thread reporting for duty" end puts "foo_finalizer thread launched" sleep 5 end end f = Foo.new f.bar f = nil ``` While trying to develop a simple test case to demonstrate the problem. It triggers rb_raise(rb_eThreadError, "can't alloc thread"); in thread_s_new, because it looks like the main thread has already been marked as 'killed' in this case. When I check the main thread status in thread_s_new with the above code, it reports 'dead'. When I run my rspec code in the sample Rails project, thread_s_new shows the main thread's status as 'run' even if it should be dead? I have seen some debugging things that shows some exceptions and thread_join interrupts and so on. Is it possible that something like this is happening? Main thread starts doing a cleanup, and gets an exception or something that generates an interrupt, and its KILLED status gets reset to RUNNABLE Then, in the finalizer, it starts creating a Thread, but at this point the main thread actually does get killed, and when that finalizer thread tries to run it runs into a null reference? I can provide the Rails sample project if needs be. Sorry if any of the above isn't clear; I've been staring at the C code for several hours and am a bit cross-eyed! Thank you for any insights. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114471] [Ruby master Bug#12500] TestProcess#test_aspawn_too_long_path fails on mips with "argument too big"
by jeremyevans0 (Jeremy Evans) 23 Aug '23

23 Aug '23

Issue #12500 has been updated by jeremyevans0 (Jeremy Evans). I submitted a pull request to handle this ArgumentError: https://github.com/ruby/ruby/pull/8270 ---------------------------------------- Bug #12500: TestProcess#test_aspawn_too_long_path fails on mips with "argument too big" https://bugs.ruby-lang.org/issues/12500#change-104244 * Author: zeha (Christian Hofstaedtler) * Status: Open * Priority: Normal * ruby -v: ruby 2.3.1p112 (2016-04-26) [mips-linux-gnu] * Backport: 2.1: UNKNOWN, 2.2: UNKNOWN, 2.3: REQUIRED ---------------------------------------- Recently in Debian we've enabled `make check` and this is one of the test failures we get for ruby2.3, on mips: ``` TestProcess#test_aspawn_too_long_path [/«PKGBUILDDIR»/test/ruby/test_process.rb:1602]: [ruby-core:34833] #7904 [ruby-core:52628] #11613. [Errno::ENOENT, Errno::E2BIG] exception expected, not. Class: <ArgumentError> Message: <"argument too big"> ---Backtrace--- /«PKGBUILDDIR»/test/ruby/test_process.rb:1619:in `*' /«PKGBUILDDIR»/test/ruby/test_process.rb:1619:in `block (3 levels) in assert_fail_too_long_path' /«PKGBUILDDIR»/test/ruby/test_process.rb:1616:in `loop' /«PKGBUILDDIR»/test/ruby/test_process.rb:1616:in `block (2 levels) in assert_fail_too_long_path' /«PKGBUILDDIR»/test/lib/test/unit/assertions.rb:74:in `assert_raise' /«PKGBUILDDIR»/test/ruby/test_process.rb:1614:in `block in assert_fail_too_long_path' /«PKGBUILDDIR»/test/lib/envutil.rb:159:in `suppress_warning' /«PKGBUILDDIR»/test/ruby/test_process.rb:1613:in `assert_fail_too_long_path' /«PKGBUILDDIR»/test/ruby/test_process.rb:1602:in `test_aspawn_too_long_path' /«PKGBUILDDIR»/test/lib/test/unit.rb:1018:in `run_test' --------------- ``` I think is caused by some array or string mangling code used by Process.spawn, but can't be sure. Please also backport any fixes for this to 2.3. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114470] [Ruby master Bug#14474] skip "TestException#test_thread_signal_location" as known bug
by jeremyevans0 (Jeremy Evans) 23 Aug '23

23 Aug '23

Issue #14474 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed This test has not been skipped since commit:5ec3450438150e7cb05422c04dc18901161a13ea in January 2022, and I don't think this has been a problem since, so I'm closing this. ---------------------------------------- Bug #14474: skip "TestException#test_thread_signal_location" as known bug https://bugs.ruby-lang.org/issues/14474#change-104243 * Author: ko1 (Koichi Sasada) * Status: Closed * Priority: Normal * ruby -v: 2.6 * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- `TestException#test_thread_signal_location` fails randomly https://gist.github.com/ko1/797b0f058f2d09ae57c9af1ee07a42b2#file-brlog-tru… > `[BUG] pthread_mutex_lock: Invalid argument (EINVAL)` https://gist.github.com/ko1/df41bb11a19792a14417c9332e70171e#file-brlog-tru… > `[BUG] Segmentation fault at 0x0000000000000000` and so on. This test consists of signal, threads, termination process, and so on. I've tried to investigate but no idea. Additionally, it is hard to reproduce. To keep CI clean, I skip this test, file about this issue and wait for a person who can solve this issue. Thanks, Koichi -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114469] [Ruby master Bug#14422] Ruby configuration options should not be reused for gem builds
by jeremyevans0 (Jeremy Evans) 23 Aug '23

23 Aug '23

Issue #14422 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed vo.x (Vit Ondruch) wrote in #note-8: > Unfortunately, this does not address the original issue. So is there any hope this will be improved upstream? I would like to avoid some rbconfig.rb hacks to remove the configuration flags in question. As @nobu stated in https://bugs.ruby-lang.org/issues/14422#note-1, use `XCFLAGS` and `XLDFLAGS` to specify options only for building Ruby, that you do not want used when building extensions. You implied you didn't want to do this, apparently without trying this approach. However, be aware that is the Ruby-supported way of supporting what you want. @nobu pointed out the issues with not using Ruby's `CFLAGS` or `LDFLAGS` by default when building Ruby extensions, so we definitely cannot make the behavior you are requesting the default as it would break things on other platforms. I don't think this is a general issue with building Ruby. If you are building packages for Ruby extensions, you should have all of Ruby's dependencies installed. If Fedora doesn't populate its buildroot with Ruby's dependencies when building packages for Ruby extensions, that does seem like a problem to be fixed in Fedora. I know not all packaging systems have Fedora's problem, because OpenBSD's packaging system does not. ---------------------------------------- Bug #14422: Ruby configuration options should not be reused for gem builds https://bugs.ruby-lang.org/issues/14422#change-104242 * Author: vo.x (Vit Ondruch) * Status: Closed * Priority: Normal * ruby -v: ruby 2.5.0p0 (2017-12-25 revision 61468) [x86_64-linux] * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- When Fedora started to harden its packages, we quite often seen complains from our users about problems installing their gems, with errors such as [1]: ~~~ gcc: error: /usr/lib/rpm/redhat/redhat-hardened-cc1: No such file or directory ~~~ The issue as analyzed by Mamoru TASAKA is [2]: > Well, if I am not mistaken, the real problem here is that rpm's %optflags is always embedded into Fedora's ruby config file, that is > > /usr/lib64/ruby/rbconfig.rb:167: CONFIG["CXXFLAGS"] = "-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -mtune=generic" > /usr/lib64/ruby/rbconfig.rb:171: CONFIG["CFLAGS"] = "-O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -mtune=generic -fPIC" > > on x86_64, for example. > > Although I am not sure this is already discussed somewhere or not, basically I think changing the default CFLAGS of "system" ruby like this way is undesirable and ? installed "rbconfig.rb" should have some "minimal" CFLAGS / CXXFLAGS. > ( for example, just like CONFIG["CFLAGS"] = "-fPIC" ) > > Only when we build Fedora gems or so (on koji), we should change CFLAGS / CXXFLAGS explicitly afterwards using %optflags. and Red Hat toolchain team responds [3]: > The current advice of the Red Hat toolchain team is to keep distribution build flags and toolchain default flags separate. This is why running “gcc” gives you the upstream defaults, and not the flags we use to compile Fedora packages. For consistency, Ruby (and other compilation support tools) follow this pattern: Use distribution flags when building for Fedora, but use upstream flags when the user compiles packages (i.e., what Ruby uses, probably something involving -O2). > > Our build flags are fully ABI-compatible with each other, so mismatches will not cause any problems at the C/C++/ABI level. The question is why Ruby does this and how we can avoid this behavior. We could force installation of redhat-rpm-config package, providing the "/usr/lib/rpm/redhat/redhat-hardened-cc1", to every ruby user, but that does not seems right. There are also other similar issues discussing this situation [4], [5]. Any thoughts? [1]: https://bugzilla.redhat.com/show_bug.cgi?id=1284684 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1284684#c6 [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1284684#c11 [4]: https://bugzilla.redhat.com/show_bug.cgi?id=1218294 [5]: https://bugzilla.redhat.com/show_bug.cgi?id=1432191 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114468] [Ruby master Bug#14418] ruby 2.5 slow regexp execution
by jeremyevans0 (Jeremy Evans) 23 Aug '23

23 Aug '23

Issue #14418 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed Thanks to very impressive work by @makenowjust, this issue has been fixed in Ruby 3.2. ---------------------------------------- Bug #14418: ruby 2.5 slow regexp execution https://bugs.ruby-lang.org/issues/14418#change-104241 * Author: jakub.wozny (Kuba W) * Status: Closed * Priority: Normal * ruby -v: 2.5 * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN ---------------------------------------- I have simple regexp that performing very slow. ~~~ ruby "fußball "*20 =~ /^([\S\s]{1000})/i ~~~ It works fast if I remove `/i` flag. I figured out that is also depends on string length or on quantifier value (in this case it is `{1000}`). When you remove `ß` form the string it also works fast. I tested on 2.3.1, 2.4.3 and 2.5.0. I'm not sure it is a bug or it just works that way. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114467] [Ruby master Bug#14064] test-all with and without -j - incorrect assertions and missing test methods
by jeremyevans0 (Jeremy Evans) 23 Aug '23

23 Aug '23

Issue #14064 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed It looks like a fix for this was committed in commit:dd3851d2786412de019350a11e749c56fa5a07cc ---------------------------------------- Bug #14064: test-all with and without -j - incorrect assertions and missing test methods https://bugs.ruby-lang.org/issues/14064#change-104240 * Author: MSP-Greg (Greg L) * Status: Closed * Priority: Normal * ruby -v: ruby 2.5.0dev (2017-10-29 trunk 60531) [x64-mingw32] * Backport: 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- I always run test-all with a `-v` parameter, and although both Travis & Appveyor scripts do not, many of the https://rubyci.org builds seem to. With `-v`, one has a log of all test methods. For quite a while, I ran ruby-loco (MinGW trunk build) with `test-all` having no `-j` parameter. I've now changed to using `-j`, and I'm surprised at what I'm finding. When run without a `-j` parameter, the total test count is correct, but the total assertions count is high. When run with a `-j` parameter (even set to 1), the test count drops (along with tests not appearing in the log), and the total assertions count is correct. Often, whole test files (classes) disappear from the log. Re the test count variance, I wrote code to parse the logs (the total test count variance), which showed which test methods were present in non-parallel test logs that were missing in parallel test logs. As to the assertions, I ran test-all on a few single files, and added the assertion count to each test method line, then compared with and without `-j`. Finally, by checking individual methods for their respective number of assertions, it was clear that the numbers shown in a non-parallel run were high. At first, it seemed that they were high by a count of three, but that only held for a few files. First of all, I'm wondering if anyone else has found similar results. Secondly, I've spent some time verifying this, but I can't seem to find where the code needs corrections to function properly. I hoped it might be a timeout issue, but that doesn't seem to be the case. Hence, suggestions as to where to start are welcome. Finally, in Travis, the line for test-all is: ``` make -s $JOBS test-all -o exts TESTOPTS='-q --color=never --job-status=normal' ``` Using MinGW, adding $JOBS as a make parameter seems to have no effect. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114466] [Ruby master Bug#13571] Script arguments, encoding, windows / MinGW
by jeremyevans0 (Jeremy Evans) 23 Aug '23

23 Aug '23

Issue #13571 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Open to Closed Starting in Ruby 3.0, arguments provided to Ruby (in `ARGV`) are now in correct UTF-8 encoding. ---------------------------------------- Bug #13571: Script arguments, encoding, windows / MinGW https://bugs.ruby-lang.org/issues/13571#change-104237 * Author: MSP-Greg (Greg L) * Status: Closed * Priority: Normal * ruby -v: ruby 2.5.0dev (2017-05-17 trunk 58774) [x64-mingw32] * Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- The following is windows/MinGW specific. I have been patching around a failure in [TestRubyOptions#test_command_line_progname_nonascii](https://github.com/rub… for a while, and decided to investigate further, assuming it was a simple issue. The following code - ```ruby # set dir to valid directory dir = "E:/temp" fn_1 = 'äÖü.rb' fn_2 = 'テスト.rb' puts puts "ENV['RUBYOPT'] #{ENV['RUBYOPT']}" \ "\nfilesystem #{Encoding.find('filesystem')}" \ "\nexternal #{Encoding.default_external}" \ "\n`chcp` #{`chcp`}" \ "locale #{Encoding.find('locale')}" \ "\n__ENCODING__ #{__ENCODING__}" \ "\ninternal #{Encoding.default_internal}\n" \ "\nfn_1 #{fn_1.encoding.to_s}" \ "\näÖü.rb #{'äÖü.rb'.encoding.to_s}" \ "\nfn_2 #{fn_2.encoding.to_s}" \ "\nテスト.rb #{'テスト.rb'.encoding.to_s}" Dir.chdir(dir) do |dir| open(fn_1, "w") { |f| f.puts "puts File.basename($0)" } open(fn_2, "w") { |f| f.puts "puts File.basename($0)" } puts puts "File.exist?(fn_1) #{File.exist?(fn_1)}" puts "File.exist?(fn_2) #{File.exist?(fn_2)}" puts puts `ruby #{fn_1}` puts `ruby #{fn_2}` end ``` produces the following output - ``` ENV['RUBYOPT'] filesystem Windows-1252 external IBM437 `chcp` Active code page: 437 locale IBM437 __ENCODING__ UTF-8 internal fn_1 UTF-8 äÖü.rb UTF-8 fn_2 UTF-8 テスト.rb UTF-8 File.exist?(fn_1) true File.exist?(fn_2) true äÖü.rb: No such file or directory @ realpath_rec - E:/temp/„™�.rb (Errno::ENOENT) ruby: Invalid argument -- ???.rb (LoadError) ``` Of note is that both files are created (and appear correctly in Explorer), but neither can be used as a script argument. Copy and pasting the names (from Explorer) on the command line produces the following similar output - ``` E:\temp>ruby äÖü.rb äÖü.rb: No such file or directory @ realpath_rec - E:/temp/„™�.rb (Errno::ENOENT) E:\temp>ruby テスト.rb ruby: Invalid argument -- ???.rb (LoadError) ``` Lastly, if before running the code I do a `chcp 1252` command to match up 'locale' and 'filesystem', the first script file runs and produces the correct output. Hence, it appears that some (or all?) `File` methods deal properly with `filesystem` encoding, but ruby script arguments are not correctly encoded. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:114465] [Ruby master Bug#13269] test/readline/test_readline.rb and mingw
by jeremyevans0 (Jeremy Evans) 23 Aug '23

23 Aug '23

Issue #13269 has been updated by jeremyevans0 (Jeremy Evans). Status changed from Assigned to Closed The readline extension was removed in commit:59fd67fc3d405e529e038172e769ff20a8fb5535. If this is still an issue, please file it upstream: https://github.com/ruby/readline-ext ---------------------------------------- Bug #13269: test/readline/test_readline.rb and mingw https://bugs.ruby-lang.org/issues/13269#change-104233 * Author: MSP-Greg (Greg L) * Status: Closed * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * ruby -v: ruby 2.5.0dev (2017-03-02 trunk 57755) [x64-mingw32] * Backport: 2.2: UNKNOWN, 2.3: UNKNOWN, 2.4: UNKNOWN ---------------------------------------- When running test-all on a mingw build, [`test_readline.rb`](https://github.com/ruby/ruby/blob/trunk/test/readline/test_readline.rb) generates failures and errors. Several of the errors are due to the `with_temp_stdio` method in `test_readline.rb`. It also leaves several undeleted files in the temp dir. Current link is: [TestReadline#with_temp_stdio](https://github.com/ruby/ruby/blob/trunk/test/… The current code is: ```ruby def with_temp_stdio Tempfile.create("test_readline_stdin") {|stdin| Tempfile.create("test_readline_stdout") {|stdout| yield stdin, stdout } } end ``` Replacing it with the following solved the problems. ```ruby def with_temp_stdio stdin = Tempfile.new("test_readline_stdin") stdout = Tempfile.new("test_readline_stdout") yield stdin, stdout if stdout stdout.closed? ? stdout.unlink : stdout.close! end if stdin stdin.closed? ? stdin.unlink : stdin.close! end end ``` I can only test on Windows, but I assume the changed code would work on other os's. If someone could test it, I'd submit a PR. Maybe the code in `Tempfile::Remover` is really where the change should occur, but I haven't looked at that. After this update, I only had one failure and three errors. Text below. Odd thing for two errors it that they report `NoMethodError: undefined method assert_separately`, but the highlighted line is `return if assert_under_utf8`. I didn't do an exhaustive search, but I can't find a reference to that function. But, I'm pulling the test files out of ruby and running separately... ``` Failure: test_input_metachar(TestReadline) D:/r_test/Readline/test_readline.rb:420:in `test_input_metachar' 417: wo = w.dup 418: wo.write("\C-re\ef\n") 419: end => 420: assert_equal("hello", line, bug6601) 421: ensure 422: wo.close 423: Readline.delete_text [ruby-core:45682] <"hello">(UTF-8) expected but was <"hfello">(IBM437) diff: ? hfello ? Encoding: UTF-8 ? IBM437 ==================================================================================================================================================== Error: test_input_metachar_multibyte(TestReadline): NoMethodError: undefined method `assert_separately' for #<TestReadline:0x00000003bcfef0> Did you mean? assert_empty D:/r_test/Readline/test_readline.rb:618:in `assert_under_utf8' D:/r_test/Readline/test_readline.rb:429:in `test_input_metachar_multibyte' 426: 427: def test_input_metachar_multibyte 428: unless Encoding.find("locale") == Encoding::UTF_8 => 429: return if assert_under_utf8 430: skip 'this test needs UTF-8 locale' 431: end 432: bug6602 = '[ruby-core:45683]' ==================================================================================================================================================== Error: test_refresh_line(TestReadline): NoMethodError: undefined method `assert_ruby_status' for #<TestReadline:0x00000003bcf6f8> Did you mean? assert_raises D:/r_test/Readline/test_readline.rb:459:in `block (2 levels) in test_refresh_line' 456: bug6232 = '[ruby-core:43957] [Bug #6232] refresh_line after set_screen_size' 457: with_temp_stdio do |stdin, stdout| 458: replace_stdio(stdin.path, stdout.path) do => 459: assert_ruby_status(%w[-rreadline -], <<-'end;', bug6232) 460: Readline.set_screen_size(40, 80) 461: Readline.refresh_line 462: end; D:/r_test/Readline/test_readline.rb:567:in `block (2 levels) in replace_stdio' D:/r_test/Readline/test_readline.rb:557:in `open' D:/r_test/Readline/test_readline.rb:557:in `block in replace_stdio' D:/r_test/Readline/test_readline.rb:556:in `open' D:/r_test/Readline/test_readline.rb:556:in `replace_stdio' D:/r_test/Readline/test_readline.rb:458:in `block in test_refresh_line' D:/r_test/Readline/test_readline.rb:583:in `with_temp_stdio' D:/r_test/Readline/test_readline.rb:457:in `test_refresh_line' ==================================================================================================================================================== Error: test_using_quoting_detection_proc_with_multibyte_input(TestReadline): NoMethodError: undefined method `assert_separately' for #<TestReadline:0x00000003bcf2c0> Did you mean? assert_empty D:/r_test/Readline/test_readline.rb:618:in `assert_under_utf8' D:/r_test/Readline/test_readline.rb:517:in `test_using_quoting_detection_proc_with_multibyte_input' 514: saved_completer_word_break_characters = Readline.completer_word_break_characters 515: return unless Readline.respond_to?(:quoting_detection_proc=) 516: unless Encoding.find("locale") == Encoding::UTF_8 => 517: return if assert_under_utf8 518: skip 'this test needs UTF-8 locale' 519: end 520: ``` -- https://bugs.ruby-lang.org/

1 0