Ruby Issue Tracking System: Issueshttps://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112021-10-01T16:39:26ZRuby Issue Tracking System
Redmine Ruby master - Bug #18235 (Closed): try_var in mkmf.rb recognizes a variable that is not declaredhttps://bugs.ruby-lang.org/issues/182352021-10-01T16:39:26ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>In 524513be399e81bb170ec88aa0d501f33cbde8c3, <code>try_var</code> in mkmf.rb has been modified to recognize a variable that exists but is not declared. What was the rationale behind this change?</p>
<p>In ext/date/extconf.rb, it checks <code>have_var("altzone", "time.h", opt)</code> . Strangely, in AIX, the variable <code>altzone</code> is not declared in <code>time.h</code> but does exist somewhere in the library. As a result, <code>extconf.rb</code> regards <code>altzone</code> as a valid variable, but compile fails because it is not declared. I think the library of AIX is weird, but the logic of <code>try_var</code> looks as weird to me. I thought the intent of <code>have_var</code>/<code>try_var</code> was to pre-check whether the compile succeeds if you use the variable, wasn't it?</p>
<p>In any case, an ad-hoc solution to this particular issue in the date module is just adding <code>#if defined(_AIX)</code> to <code>ext/date/date_core.c</code>, but I'm curious if <code>try_var</code> could lead to other issues in the future.</p>
<p>Thanks,</p> Ruby master - Bug #16814 (Closed): Segmentation fault in GC while running test/ruby/test_fiber.rb...https://bugs.ruby-lang.org/issues/168142020-04-24T05:31:26ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>A segmentation fault almost always happens in test/ruby/test_fiber.rb with certain commits of latest Ruby on s390x.</p>
<pre><code>$ make test-all TESTS=test/ruby/test_fiber.rb
Run options:
--seed=90044
"--ruby=./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems"
--excludes-dir=./test/excludes
--name=!/memory_leak/
# Running tests:
[24/29] TestFiber#test_stack_size = 0.89 s
1) Failure:
TestFiber#test_stack_size [/home/chkbuild/my-tmp/build/20200412T043305Z/ruby/test/ruby/test_fiber.rb:356]:
pid 5713 killed by SIGABRT (signal 6) (core dumped)
| -e:1:in `print': stack level too deep (SystemStackError)
| from -e:1:in `rec'
| from -e:1:in `block (3 levels) in rec'
| from -e:1:in `times'
| from -e:1:in `block (2 levels) in rec'
| from -e:1:in `times'
| from -e:1:in `block in rec'
| from -e:1:in `times'
| from -e:1:in `rec'
| ... 172 levels...
| from -e:1:in `block in rec'
| -e: [BUG] Segmentation fault at 0x0000000000000000
| ruby 2.8.0dev (2020-04-12T03:45:22Z master 5c27681813) [s390x-linux]
|
| -- Control frame information -----------------------------------------------
| c:0001 p:0000 s:0003 E:001e20 (none) [FINISH]
|
|
| -- Other runtime information -----------------------------------------------
|
| * Loaded script: -e
|
| * Loaded features:
|
| 0 enumerator.so
| 1 thread.rb
| 2 rational.so
| 3 complex.so
| 4 ruby2_keywords.rb
| 5 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/.ext/s390x-linux/enc/encdb.so
| 6 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/.ext/s390x-linux/enc/trans/transdb.so
| 7 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/rbconfig.rb
| 8 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/rubygems/compatibility.rb
| 9 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/rubygems/defaults.rb
| 10 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/rubygems/deprecate.rb
| 11 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/rubygems/errors.rb
| 12 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/rubygems/version.rb
| 13 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/rubygems/requirement.rb
| 14 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/rubygems/platform.rb
| 15 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/rubygems/basic_specification.rb
| 16 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/rubygems/stub_specification.rb
| 17 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/rubygems/util.rb
| 18 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/rubygems/text.rb
| 19 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/rubygems/user_interaction.rb
| 20 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/rubygems/specification_policy.rb
| 21 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/rubygems/util/list.rb
| 22 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/rubygems/specification.rb
| 23 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/rubygems/exceptions.rb
| 24 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/rubygems/bundler_version_finder.rb
| 25 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/rubygems/dependency.rb
| 26 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/rubygems/core_ext/kernel_gem.rb
| 27 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/.ext/s390x-linux/monitor.so
| 28 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/.ext/common/monitor.rb
| 29 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/rubygems/core_ext/kernel_require.rb
| 30 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/rubygems/core_ext/kernel_warn.rb
| 31 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/rubygems.rb
| 32 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/did_you_mean/version.rb
| 33 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/did_you_mean/core_ext/name_error.rb
| 34 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/did_you_mean/levenshtein.rb
| 35 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/did_you_mean/jaro_winkler.rb
| 36 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/did_you_mean/spell_checker.rb
| 37 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/did_you_mean/spell_checkers/name_error_checkers/class_name_checker.rb
| 38 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/did_you_mean/spell_checkers/name_error_checkers/variable_name_checker.rb
| 39 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/did_you_mean/spell_checkers/name_error_checkers.rb
| 40 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/did_you_mean/spell_checkers/method_name_checker.rb
| 41 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/did_you_mean/spell_checkers/key_error_checker.rb
| 42 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/did_you_mean/spell_checkers/null_checker.rb
| 43 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/did_you_mean/formatters/plain_formatter.rb
| 44 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/did_you_mean/tree_spell_checker.rb
| 45 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/lib/did_you_mean.rb
|
| * Process memory map:
|
| 2aa15380000-2aa15772000 r-xp 00000000 5e:01 1198050 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/ruby
| 2aa15772000-2aa15777000 r--p 003f1000 5e:01 1198050 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/ruby
| 2aa15777000-2aa15779000 rw-p 003f6000 5e:01 1198050 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/ruby
| 2aa15779000-2aa15787000 rw-p 00000000 00:00 0
| 2aa29766000-2aa29ab0000 rw-p 00000000 00:00 0 [heap]
| 3ffaa180000-3ffaa182000 r-xp 00000000 5e:01 1197862 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/.ext/s390x-linux/monitor.so
| 3ffaa182000-3ffaa183000 r--p 00001000 5e:01 1197862 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/.ext/s390x-linux/monitor.so
| 3ffaa183000-3ffaa184000 rw-p 00002000 5e:01 1197862 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/.ext/s390x-linux/monitor.so
| 3ffaa200000-3ffaa202000 r-xp 00000000 5e:01 1198135 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/.ext/s390x-linux/enc/trans/transdb.so
| 3ffaa202000-3ffaa203000 ---p 00002000 5e:01 1198135 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/.ext/s390x-linux/enc/trans/transdb.so
| 3ffaa203000-3ffaa204000 r--p 00002000 5e:01 1198135 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/.ext/s390x-linux/enc/trans/transdb.so
| 3ffaa204000-3ffaa205000 rw-p 00003000 5e:01 1198135 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/.ext/s390x-linux/enc/trans/transdb.so
| 3ffaab76000-3ffacc80000 rw-p 00000000 00:00 0
| 3ffacc80000-3ffacc82000 r-xp 00000000 5e:01 133388 /usr/lib64/libfreebl3.so
| 3ffacc82000-3ffacc83000 r--p 00001000 5e:01 133388 /usr/lib64/libfreebl3.so
| 3ffacc83000-3ffacc84000 rw-p 00002000 5e:01 133388 /usr/lib64/libfreebl3.so
| 3ffacd00000-3ffaceaf000 r-xp 00000000 5e:01 134626 /usr/lib64/libc-2.17.so
| 3ffaceaf000-3ffaceb3000 r--p 001ae000 5e:01 134626 /usr/lib64/libc-2.17.so
| 3ffaceb3000-3ffaceb5000 rw-p 001b2000 5e:01 134626 /usr/lib64/libc-2.17.so
| 3ffaceb5000-3ffaceb9000 rw-p 00000000 00:00 0
| 3ffacf00000-3ffacfa8000 r-xp 00000000 5e:01 135803 /usr/lib64/libm-2.17.so
| 3ffacfa8000-3ffacfa9000 r--p 000a7000 5e:01 135803 /usr/lib64/libm-2.17.so
| 3ffacfa9000-3ffacfaa000 rw-p 000a8000 5e:01 135803 /usr/lib64/libm-2.17.so
| 3ffad000000-3ffad00d000 r-xp 00000000 5e:01 135760 /usr/lib64/libcrypt-2.17.so
| 3ffad00d000-3ffad00e000 r--p 0000c000 5e:01 135760 /usr/lib64/libcrypt-2.17.so
| 3ffad00e000-3ffad00f000 rw-p 0000d000 5e:01 135760 /usr/lib64/libcrypt-2.17.so
| 3ffad00f000-3ffad03d000 rw-p 00000000 00:00 0
| 3ffad080000-3ffad083000 r-xp 00000000 5e:01 135797 /usr/lib64/libdl-2.17.so
| 3ffad083000-3ffad084000 r--p 00002000 5e:01 135797 /usr/lib64/libdl-2.17.so
| 3ffad084000-3ffad085000 rw-p 00003000 5e:01 135797 /usr/lib64/libdl-2.17.so
| 3ffad100000-3ffad187000 r-xp 00000000 5e:01 136942 /usr/lib64/libgmp.so.10.2.0
| 3ffad187000-3ffad189000 r--p 00086000 5e:01 136942 /usr/lib64/libgmp.so.10.2.0
| 3ffad189000-3ffad18a000 rw-p 00088000 5e:01 136942 /usr/lib64/libgmp.so.10.2.0
| 3ffad200000-3ffad208000 r-xp 00000000 5e:01 136149 /usr/lib64/librt-2.17.so
| 3ffad208000-3ffad209000 r--p 00007000 5e:01 136149 /usr/lib64/librt-2.17.so
| 3ffad209000-3ffad20a000 rw-p 00008000 5e:01 136149 /usr/lib64/librt-2.17.so
| 3ffad280000-3ffad298000 r-xp 00000000 5e:01 135793 /usr/lib64/libpthread-2.17.so
| 3ffad298000-3ffad299000 r--p 00017000 5e:01 135793 /usr/lib64/libpthread-2.17.so
| 3ffad299000-3ffad29a000 rw-p 00018000 5e:01 135793 /usr/lib64/libpthread-2.17.so
| 3ffad29a000-3ffad29e000 rw-p 00000000 00:00 0
| 3ffad300000-3ffad317000 r-xp 00000000 5e:01 136264 /usr/lib64/libz.so.1.2.7
| 3ffad317000-3ffad318000 r--p 00016000 5e:01 136264 /usr/lib64/libz.so.1.2.7
| 3ffad318000-3ffad319000 rw-p 00017000 5e:01 136264 /usr/lib64/libz.so.1.2.7
| 3ffad380000-3ffad382000 r-xp 00000000 5e:01 1198055 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/.ext/s390x-linux/enc/encdb.so
| 3ffad382000-3ffad383000 r--p 00001000 5e:01 1198055 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/.ext/s390x-linux/enc/encdb.so
| 3ffad383000-3ffad384000 rw-p 00002000 5e:01 1198055 /home/chkbuild/my-tmp/build/20200412T043305Z/ruby/.ext/s390x-linux/enc/encdb.so
| 3ffad39f000-3ffad400000 rw-p 00000000 00:00 0
| 3ffad400000-3ffad423000 r-xp 00000000 5e:01 133698 /usr/lib64/ld-2.17.so
| 3ffad424000-3ffad425000 r--p 00023000 5e:01 133698 /usr/lib64/ld-2.17.so
| 3ffad425000-3ffad426000 rw-p 00024000 5e:01 133698 /usr/lib64/ld-2.17.so
| 3ffad426000-3ffad427000 rw-p 00000000 00:00 0
| 3ffad473000-3ffad47e000 rw-p 00000000 00:00 0
| 3ffad47e000-3ffad480000 r-xp 00000000 00:00 0 [vdso]
| 3ffdb181000-3ffdb980000 rw-p 00000000 00:00 0 [stack]
|
|
Finished tests in 7.935617s, 3.6544 tests/s, 23.9427 assertions/s.
29 tests, 190 assertions, 1 failures, 0 errors, 0 skips
ruby -v: ruby 2.8.0dev (2020-04-12T03:45:22Z master 5c27681813) [s390x-linux]
make: *** [yes-test-all] Error 1
</code></pre>
<p>The segmentation fault happens in a Ruby script invoked from test_fiber.rb by <code>EnvUtil.invoke_ruby()</code>. The Ruby script is to deliberately cause a stack overflow as follows.</p>
<pre><code>$stdout.sync=true; def rec; print "."; 1.times{1.times{1.times{rec}}}; end; Fiber.new{rec}.resume
</code></pre>
<p>On s390x, this script caused SystemStackError, which I think is expected. However, it was during the handling of the stack overflow when the segmentation fault happened.</p>
<p>The core dump shows the following stack trace.</p>
<pre><code>(gdb) bt
#0 0x000003ffb62c1350 in raise () from /lib64/libc.so.6
#1 0x000003ffb62c2bd8 in abort () from /lib64/libc.so.6
#2 0x000002aa0c84bf9a in die () at error.c:646
#3 rb_bug_for_fatal_signal (default_sighandler=0x0, sig=sig@entry=11,
ctx=ctx@entry=0x2aa2d18fc50,
fmt=fmt@entry=0x2aa0c89352c "Segmentation fault at %p") at error.c:678
#4 0x000002aa0c6fbd60 in sigsegv (sig=<optimized out>, info=0x2aa2d18fbd0,
ctx=0x2aa2d18fc50) at signal.c:955
#5 <signal handler called>
#6 0x000002aa0c5d1f36 in gc_mark_children (
objspace=objspace@entry=0x2aa2d09c6b0, obj=obj@entry=2929923415200)
at gc.c:5478
#7 0x000002aa0c5d3ac8 in rgengc_rememberset_mark (heap=0x2aa2d09c6d8,
objspace=0x2aa2d09c6b0) at gc.c:6747
#8 gc_marks_start (full_mark=<optimized out>, objspace=0x2aa2d09c6b0)
at gc.c:6314
#9 gc_marks (full_mark=<optimized out>, objspace=0x2aa2d09c6b0) at gc.c:6583
#10 gc_start (objspace=objspace@entry=0x2aa2d09c6b0, reason=<optimized out>,
reason@entry=256) at gc.c:7370
#11 0x000002aa0c5a9370 in heap_prepare (heap=0x2aa2d09c6d8,
objspace=<optimized out>) at gc.c:1977
#12 heap_get_freeobj_from_next_freepage (
objspace=objspace@entry=0x2aa2d09c6b0, heap=heap@entry=0x2aa2d09c6d8)
at gc.c:1989
---Type <return> to continue, or q <return> to quit---
#13 0x000002aa0c5d7cb0 in heap_get_freeobj (heap=0x2aa2d09c6d8,
objspace=0x2aa2d09c6b0) at gc.c:2028
#14 newobj_slowpath (wb_protected=1, objspace=0x2aa2d09c6b0, v3=v3@entry=0,
v2=0, v1=0, flags=5, klass=2929923683840) at gc.c:2170
#15 newobj_slowpath_wb_protected (klass=2929923683840, flags=5, v1=v1@entry=0,
v2=v2@entry=0, v3=v3@entry=0, objspace=0x2aa2d09c6b0) at gc.c:2182
#16 0x000002aa0c5d817c in newobj_of (wb_protected=1, v3=0, v2=0, v1=0,
flags=5, klass=<optimized out>) at gc.c:2218
#17 rb_wb_protected_newobj_of (klass=<optimized out>, flags=flags@entry=5)
at gc.c:2234
#18 0x000002aa0c710fa2 in str_alloc (klass=<optimized out>) at string.c:745
#19 str_new0 (klass=<optimized out>, ptr=0x2aa0c85ad0e "\t", len=1,
termlen=<optimized out>) at string.c:767
#20 0x000002aa0c5b1f28 in ruby3_str_new_cstr (str=0x2aa0c85ad0e "\t")
at ./include/ruby/3/intern/string.h:159
#21 print_backtrace (eclass=2929923530680, errat=errat@entry=2929923354920,
str=str@entry=8, reverse=reverse@entry=0) at eval_error.c:250
#22 0x000002aa0c5b3f68 in print_backtrace (reverse=0, str=8,
errat=<optimized out>, eclass=<optimized out>) at eval_error.c:233
#23 rb_error_write (reverse=0, highlight=0, str=8, errat=<optimized out>,
emesg=2929923530600, errinfo=<optimized out>) at eval_error.c:340
#24 rb_ec_error_print (ec=ec@entry=0x2aa2d09cb40, errinfo=<optimized out>)
at eval_error.c:365
#25 0x000002aa0c5b4572 in error_handle (ec=0x2aa2d09cb40, ex=<optimized out>)
---Type <return> to continue, or q <return> to quit---
at eval_error.c:478
#26 0x000002aa0c5b4d50 in rb_ec_cleanup (ec=ec@entry=0x2aa2d09cb40,
ex=<optimized out>) at eval.c:241
#27 0x000002aa0c5b565a in ruby_run_node (n=0x2aa2d0b6128) at eval.c:348
#28 0x000002aa0c5af68a in main (argc=3, argv=0x3ffd127e9e8) at ./main.c:50
</code></pre>
<p>At gc.c:5478, the segmentation fault happened because <code>any->as.typeddata.type</code> was 0. <code>as.typeddata.type</code> should not be 0 for RTypedData.</p>
<pre><code> 5473 case T_DATA:
5474 {
5475 void *const ptr = DATA_PTR(obj);
5476 if (ptr) {
5477 RUBY_DATA_FUNC mark_func = RTYPEDDATA_P(obj) ?
5478 any->as.typeddata.type->function.dmark :
5479 any->as.data.dmark;
5480 if (mark_func) (*mark_func)(ptr);
5481 }
5482 }
5483 break;
</code></pre>
<p>This is a timing bug, but it almost always happens with 5c27681813. It is not clear to which commit this issue is related. In Ruby CI, it started happening in early February 2020 and stopped showing up after increasing the stack size by <code>ulimit -s</code>. It started happening again in early April 2020 and disappeared on April 15.</p>
<p>Anybody has any ideas how I should debug this?</p> Ruby master - Bug #14321 (Closed): Backport r54803 (Fix Math.lgamma on AIX)https://bugs.ruby-lang.org/issues/143212018-01-05T22:14:38ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>This is a ticket to back-port r54803 to 2.3.</p> Ruby master - Bug #12227 (Closed): Backport r54137 and r54184 (Fix a test that depends on dayligh...https://bugs.ruby-lang.org/issues/122272016-03-28T19:39:33ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>This is a ticket to back-port r54137 and r54184 to 2.3.</p> Ruby master - Bug #12168 (Closed): Backport r48224 to 2.1https://bugs.ruby-lang.org/issues/121682016-03-11T00:16:38ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>This is a ticket to back-port r48224 (and the fixes on which it depends) to 2.1. Ruby 2.1 gets stuck in test/openssl/test_ssl.rb on AIX, and r48224 solves this problem. r48224 depends on r46108, r46209, r46223, r46297, and r48223.</p> Ruby master - Bug #12167 (Closed): Backport r54025 (Avoid false positive in an IMAP test)https://bugs.ruby-lang.org/issues/121672016-03-10T20:00:26ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>This is a ticket to back-port r54025 to 2.3.</p> Ruby master - Bug #12166 (Closed): Backport r54073 (AIX does not set MSG_TRUC for recvmsg(2) with...https://bugs.ruby-lang.org/issues/121662016-03-10T19:46:53ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>This is a ticket to back-port r54073 to 2.3.</p> Ruby master - Bug #12155 (Closed): Backport r47837 (AIX does not allow getsid(pid) when pid is in...https://bugs.ruby-lang.org/issues/121552016-03-07T21:06:42ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>This is a ticket to back-port r47837 to 2.1.</p> Ruby master - Bug #12154 (Closed): Backport r54010 (avoid a setgid test on AIX)https://bugs.ruby-lang.org/issues/121542016-03-07T21:02:14ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>This is a ticket to back-port r54010 to 2.1, 2.2, and 2.3.</p> Ruby master - Bug #12153 (Closed): Backport r54003 (nextafter(3) on AIX is broken with +0.0 and -...https://bugs.ruby-lang.org/issues/121532016-03-07T20:47:01ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>This is a ticket to back-port r54003 to 2.2 and 2.3.</p> Ruby master - Bug #12152 (Closed): Backport r54004 (the fifth argument to getsockopt(2) is not mo...https://bugs.ruby-lang.org/issues/121522016-03-07T20:37:26ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>This is a ticket to back-port r54004 to 2.1, 2.2, and 2.3. Back-port of the change in test/socket/test_sockopt.rb not required for 2.2 or 2.3.</p> Ruby master - Bug #12151 (Closed): Backport r54002 (zconf.h in zlib does not recognize _LARGE_FIL...https://bugs.ruby-lang.org/issues/121512016-03-07T20:17:23ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>This is a ticket to back-port r54002 to 2.1, 2.2, and 2.3.</p> Ruby master - Bug #12150 (Closed): Backport r54005 (ipv6_v4compat? and ipv6_v4mapped? are broken ...https://bugs.ruby-lang.org/issues/121502016-03-07T19:59:46ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>This is a ticket to back-port r54005 to 2.1, 2.2, and 2.3.</p> Ruby master - Bug #12149 (Closed): Backport r51930 (test_s_open_lock hangs on AIX)https://bugs.ruby-lang.org/issues/121492016-03-07T19:40:00ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>This is a ticket to back-port r51930 to 2.1 and 2.2 (not to 2.3).</p> Ruby master - Bug #12148 (Closed): Backport r54000 (__pi_stacksize returned by pthread_getthrds_n...https://bugs.ruby-lang.org/issues/121482016-03-07T18:47:25ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>This is a ticket to back-port r54000 to 2.1, 2.2, and 2.3.</p> Ruby master - Bug #11792 (Closed): Backport r52199 (pthread_getattr_np is broken on AIX)https://bugs.ruby-lang.org/issues/117922015-12-08T23:48:19ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>This is a ticket to manage back-porting r52199 to 2.1 and 2.2.</p> Ruby master - Bug #11483 (Closed): internal.h included after math.h in complex.chttps://bugs.ruby-lang.org/issues/114832015-08-24T18:55:59ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>r51313 modified complex.c to include internal.h after math.h, so that ruby/missing.h (included from internal.h) can test whether <code>M_PI</code> is defined or not in math.h. Unfortunately, ruby/config.h, which is included from internal.h, defines <code>_LARGE_FILES</code>, which must be defined before sys/types.h is included from math.h. Otherwise, in AIX, <code>off_t</code> would be incorrectly defined as a 32-bit integer even when large files are used.</p>
<pre><code class="diff syntaxhl" data-language="diff"><span class="gd">--- complex.c (revision 51312)
</span><span class="gi">+++ complex.c (revision 51313)
</span><span class="p">@@ -5,12 +5,12 @@</span>
which is written in ruby.
*/
<span class="gd">-#include "internal.h"
</span> #if defined _MSC_VER
/* Microsoft Visual C does not define M_PI and others by default */
# define _USE_MATH_DEFINES 1
#endif
#include <math.h>
<span class="gi">+#include "internal.h"
</span>
#define NDEBUG
#include <assert.h>
</code></pre>
<p>There would be a couple of workarounds to fix this problem, but since I am relatively new to the Ruby core, I am wondering what would be the most acceptable way.</p> Ruby master - Bug #9928 (Closed): Fiddle::TestHandle#test_NEXT fails on AIX due to unexported sym...https://bugs.ruby-lang.org/issues/99282014-06-10T20:07:55ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p><code>Fiddle::TestHandle#test_NEXT</code> fails on AIX.</p>
<pre><code>[ 4/21] Fiddle::TestHandle#test_NEXT = 0.00 s
1) Error:
Fiddle::TestHandle#test_NEXT:
Fiddle::DLError: unknown symbol "Init_objspace"
/ss/home/rayod/Dev/Contribution/ruby-trunk-blue1/test/fiddle/test_handle.rb:171:in `[]'
/ss/home/rayod/Dev/Contribution/ruby-trunk-blue1/test/fiddle/test_handle.rb:171:in `rescue in test_NEXT'
/ss/home/rayod/Dev/Contribution/ruby-trunk-blue1/test/fiddle/test_handle.rb:144:in `test_NEXT'
</code></pre>
<p>The reason for this is a little bit complicated. <code>Fiddle::TestHandle#test_NEXT</code> tests the behavior of <code>RTLD_NEXT</code> for <code>dlsym(3)</code>. According to the manual, <code>RTLD_NEXT</code> of AIX should behave like that of BSD, so the following part in <code>Fiddle::TestHandle#test_NEXT</code> should succeed, but in fact it fails.</p>
<pre><code> # BSD
#
<snip>
require 'objspace'
handle = Handle::NEXT
refute_nil handle['Init_objspace']
</code></pre>
<p>The problem is that on AIX, Ruby's extension libraries do not export their symbols, because they are loaded not by dlopen(3)/dlsym(3) but by load(3). The build process on AIX only specifies <code>Init_*</code> functions as the entry points of the extension shared libraries. This means <code>Init_objspace</code> cannot be the search target of <code>RTLD_NEXT</code>, and the test above results in nil. (FYI, the symbols in the modules loaded by load(3) can be found by <code>RTLD_NEXT</code> if they are exported.)</p>
<p>One way to solve this is to somehow export the <code>Init_objspace</code> function. However, specifying -Wl,-bexpall does not export the entry points, so we need to specify -Wl,-bexpfull, which looks like overkill for just passing this test.</p>
<p>Fortunately, on AIX, test/fiddle/helper.rb creates and loads a dummy shared library, libaixdltest.so, which contains and exports <code>strcpy</code> and some other functions, so we can take advantage of it for testing <code>RTLD_NEXT</code>. That is, we can simply query <code>strcpy</code> to check whether or not <code>RTLD_NEXT</code> works correctly, as follows. The patch is attached.</p>
<pre><code> handle = Handle::NEXT
refute_nil handle['strcpy']
</code></pre> Ruby master - Bug #9917 (Closed): TestIO#test_io_select_with_many_files results in timeout expira...https://bugs.ruby-lang.org/issues/99172014-06-07T12:12:29ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>On AIX, time-out for <code>TestIO#test_io_select_with_many_files</code> expires because it takes more than 10 seconds to remove 1024< temporary files. The test itself succeeds if the time-out period is extended.</p>
<pre><code>[ 85/170] TestIO#test_io_select_with_many_files = 11.06 s
2) Error:
TestIO#test_io_select_with_many_files:
Timeout::Error: execution of assert_normal_exit expired
/ss/home/rayod/Dev/Contribution/ruby-trunk-blue1/test/ruby/test_io.rb:2935:in `test_io_select_with_many_files'
</code></pre>
<p>How about extending the time-out period to 30 seconds?</p>
<pre><code class="diff syntaxhl" data-language="diff"><span class="gd">--- test/ruby/test_io.rb (revision 46310)
</span><span class="gi">+++ test/ruby/test_io.rb (working copy)
</span><span class="p">@@ -2952,7 +2952,7 @@</span>
}
IO.select(tempfiles)
<span class="gd">- }, bug8080
</span><span class="gi">+ }, bug8080, timeout: 30
</span> end
def test_read_32bit_boundary
</code></pre> Ruby master - Bug #9914 (Closed): posix_fadvise() does not work correctly with _LARGE_FILES on 32...https://bugs.ruby-lang.org/issues/99142014-06-06T19:51:34ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p><code>test_advise</code> in <code>test/ruby/test_io.rb</code> fails on AIX.</p>
<pre><code>[ 1/170] TestIO#test_advise = 0.01 s
1) Error:
TestIO#test_advise:
Errno::EINVAL: Invalid argument - /tmp/test_io20140606-7733390-1xgpc07
/ss/home/rayod/Dev/Contribution/ruby-trunk-blue1/test/ruby/test_io.rb:2437:in `advise'
/ss/home/rayod/Dev/Contribution/ruby-trunk-blue1/test/ruby/test_io.rb:2437:in `block (4 levels) in test_advise'
/ss/home/rayod/Dev/Contribution/ruby-trunk-blue1/test/ruby/test_io.rb:2436:in `open'
/ss/home/rayod/Dev/Contribution/ruby-trunk-blue1/test/ruby/test_io.rb:2436:in `block (3 levels) in test_advise'
/ss/home/rayod/Dev/Contribution/ruby-trunk-blue1/test/ruby/test_io.rb:2435:in `each'
/ss/home/rayod/Dev/Contribution/ruby-trunk-blue1/test/ruby/test_io.rb:2435:in `block (2 levels) in test_advise'
/ss/home/rayod/Dev/Contribution/ruby-trunk-blue1/test/ruby/test_io.rb:2434:in `each'
/ss/home/rayod/Dev/Contribution/ruby-trunk-blue1/test/ruby/test_io.rb:2434:in `block in test_advise'
/ss/home/rayod/Dev/Contribution/ruby-trunk-blue1/test/ruby/test_io.rb:1442:in `make_tempfile'
/ss/home/rayod/Dev/Contribution/ruby-trunk-blue1/test/ruby/test_io.rb:2432:in `test_advise'
</code></pre>
<p>It is very strange, but the current AIX does not seem to support a 32-bit call to <code>posix_fadvise()</code> when <code>_LARGE_FILES</code> is defined.<br>
<a href="http://www-01.ibm.com/support/docview.wss?uid=isg1IV56170" class="external">http://www-01.ibm.com/support/docview.wss?uid=isg1IV56170</a></p>
<p>Until it is supported, we need this ugly patch to not call <code>posix_fadvise()</code>....</p>
<pre><code class="diff syntaxhl" data-language="diff"><span class="gd">--- io.c (revision 46310)
</span><span class="gi">+++ io.c (working copy)
</span><span class="p">@@ -8586,7 +8586,10 @@</span>
off = NIL_P(offset) ? 0 : NUM2OFFT(offset);
l = NIL_P(len) ? 0 : NUM2OFFT(len);
<span class="gd">-#ifdef HAVE_POSIX_FADVISE
</span><span class="gi">+ /* AIX currently does not support a 32-bit call to posix_fadvise()
+ * if _LARGE_FILES is defined.
+ */
+#if defined(HAVE_POSIX_FADVISE) && !(defined(_AIX) && defined(_LARGE_FILES) && !defined(_ARCH_PPC64))
</span> return do_io_advise(fptr, advice, off, l);
#else
((void)off, (void)l); /* Ignore all hint */
<span class="err">
</span></code></pre>
<p>FYI, detailed explanation follows:<br>
The 2nd and 3rd arguemnts to <code>posix_fadvise()</code> are the <code>off_t</code> type. If <code>_LARGE_FILES</code> is defined, <code>off_t</code> is defined as <code>long long int</code> on the caller side. This means the 2nd and 3rd arguments are passed using two registers each on a 32-bit environment. However, the callee side does not support <code>_LARGE_FILES</code>, so <code>off_t</code> is assumed to be <code>long int</code>, which is passed using one register. As a result, the callee side can not receive a correct value for the 4th argument, <code>int advice</code>, throwing EINVAL.</p> Ruby master - Bug #9905 (Closed): Fiber does not work on AIXhttps://bugs.ruby-lang.org/issues/99052014-06-05T09:19:56ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p><code>test/ruby/test_fiber.rb</code> fails on AIX.</p>
<pre><code>[ 2/23] TestFiber#test_argument/ss/home/rayod/Dev/Contribution/ruby-trunk-blue1/test/ruby/test_fiber.rb:19: [BUG] machine_stack_cache size is not canonicalized
ruby 2.2.0dev (2014-06-02 trunk 45270) [powerpc-aix7.1.0.0]
</code></pre>
<p>Here is what happens for this test:</p>
<ol>
<li>A fiber is created by setting <code>context->uc_stack.ss_size</code> to a certain value and calling <code>makecontext()</code>.</li>
<li>While the fiber is switched with other fibers by <code>swapcontext()</code>, <code>context->uc_stack.ss_size</code> is changed to a very large value by AIX.</li>
<li>When the fiber finishes, its stack pointer and size are cached in <code>machine_stack_cache[]</code>.</li>
<li>When a new fiber is created, a specified stack size is different from the cached stack size, so the error is thrown.</li>
</ol>
<p>I feel AIX's behavior is strange, but I also suppose in general, <code>context->uc_stack.ss_size</code> is not guaranteed to be preserved after <code>makecontext()</code> or <code>swapcontext()</code>. (Please correct me if I am wrong.)</p>
<p>Rather than disabling <code>FIBER_USE_NATIVE</code> for AIX, I propose saving the original stack pointer and size not in <code>ucontext_t</code> but in new dedicated fields in <code>rb_fiber_t</code>, as you can find in the attached patch. With this patch, <code>test/ruby/test_fiber.rb</code> results in no errors on AIX. This did not cause any error on Linux, either, for test or test-all.</p> Ruby master - Bug #9884 (Closed): thread_pthread.c assumes pthread_t is a scalar typehttps://bugs.ruby-lang.org/issues/98842014-05-30T09:07:38ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>Many code lines in <code>thread_pthread.c</code> assume <code>pthread_t</code> is a scalar type. For example,</p>
<pre><code> thread_debug("ubf_select_each (%p)\n", (void *)th->thread_id);
</code></pre>
<p>and</p>
<pre><code> if (!timer_thread_id) {
</code></pre>
<p>I don't think the standard guarantees <code>pthread_t</code> is a scalar type. z/OS defines <code>pthread_t</code> as a struct, and there seem to be other such environments.<br>
<a href="https://sourceware.org/pthreads-win32/faq.html" class="external">https://sourceware.org/pthreads-win32/faq.html</a></p>
<p>I understand it could be too cumbersome to rewrite the source, assuming <code>pthread_t</code> might not be a scalar, and actually I am not sure what would be the best way to rewrite it, but I appreciate it if you guys could think of it for the maximum portability. If needed, I am willing to list the source lines to be rewritten.</p> Ruby master - Bug #9878 (Closed): ruby_signal() should return either sa_sigaction or sa_handler, ...https://bugs.ruby-lang.org/issues/98782014-05-29T09:52:47ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p><code>ruby_signal()</code> in signal.c returns <code>old.sa_handler</code>,<br>
but it should return either <code>old.sa_sigaction</code> or <code>old.sa_handler</code>,<br>
depending on whether <code>SA_SIGINFO</code> is set in <code>old.sa_flags</code>.</p>
<pre><code class="diff syntaxhl" data-language="diff"><span class="gd">--- signal.c (revision 46222)
</span><span class="gi">+++ signal.c (working copy)
</span><span class="p">@@ -595,7 +595,10 @@</span>
rb_bug_errno("sigaction", errno);
}
}
<span class="gd">- return old.sa_handler;
</span><span class="gi">+ if (old.sa_flags & SA_SIGINFO)
+ return (sighandler_t)old.sa_sigaction;
+ else
+ return old.sa_handler;
</span> }
sighandler_t
</code></pre>
<p>The original code happens to be correct on the environments<br>
where <code>sa_handler</code> and <code>sa_sigaction</code> are union, but it is not<br>
guaranteed in general.</p>
<p>(Actually, they are not union on z/OS.)</p> Ruby master - Bug #9818 (Closed): __builtin_setjmp and __builtin_longjmp caused a build failure o...https://bugs.ruby-lang.org/issues/98182014-05-08T21:13:33ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>From a certain revision around r45503 to r45515, Ruby began to use <code>__builtin_setjmp</code> and <code>__builtin_longjmp</code> on PPC Linux, instead of <code>_setjmp</code> and <code>_longjmp</code>. However, <code>__builtin_setjmp</code> and <code>__builtin_longjmp</code> cause a build failure because they are not compatible with the -fPIE option, at least with gcc 4.4.0 on PPC Linux.</p>
<pre><code>compiling eval.c
eval.c: In function ?setup_exception?:
eval.c:515: warning: ?_th? may be used uninitialized in this function
eval.c:467: warning: ?file? may be used uninitialized in this function
eval.c: In function ?ruby_setup?:
eval.c:55: warning: ?_th? may be used uninitialized in this function
eval.c: In function ?ruby_options?:
eval.c:97: warning: ?_th? may be used uninitialized in this function
In file included from eval.c:31:
eval_jump.c: In function ?rb_exec_end_proc?:
eval_jump.c:119: warning: ?_th? may be used uninitialized in this function
eval_jump.c:116: warning: ?th? may be used uninitialized in this function
eval.c: In function ?ruby_cleanup?:
eval.c:174: warning: ?_th? may be used uninitialized in this function
eval.c:184: warning: ?_th? may be used uninitialized in this function
eval.c:164: warning: ?_th? may be used uninitialized in this function
/tmp/cc9lE3AW.s: Assembler messages:
/tmp/cc9lE3AW.s:16477: Error: symbol `.LCF26' is already defined
/tmp/cc9lE3AW.s:16935: Error: symbol `.LCF28' is already defined
/tmp/cc9lE3AW.s:16967: Error: symbol `.LCF28' is already defined
/tmp/cc9lE3AW.s:17260: Error: symbol `.LCF29' is already defined
/tmp/cc9lE3AW.s:17860: Error: symbol `.LCF32' is already defined
/tmp/cc9lE3AW.s:19246: Error: symbol `.LCF38' is already defined
/tmp/cc9lE3AW.s:19256: Error: symbol `.LCF38' is already defined
/tmp/cc9lE3AW.s:19599: Error: symbol `.LCF41' is already defined
/tmp/cc9lE3AW.s:24083: Error: symbol `.LCF65' is already defined
/tmp/cc9lE3AW.s:25419: Error: symbol `.LCF68' is already defined
/tmp/cc9lE3AW.s:25429: Error: symbol `.LCF68' is already defined
/tmp/cc9lE3AW.s:25798: Error: symbol `.LCF69' is already defined
/tmp/cc9lE3AW.s:26042: Error: symbol `.LCF70' is already defined
/tmp/cc9lE3AW.s:26301: Error: symbol `.LCF72' is already defined
/tmp/cc9lE3AW.s:26313: Error: symbol `.LCF72' is already defined
/tmp/cc9lE3AW.s:26668: Error: symbol `.LCF72' is already defined
/tmp/cc9lE3AW.s:26701: Error: symbol `.LCF72' is already defined
/tmp/cc9lE3AW.s:26712: Error: symbol `.LCF72' is already defined
/tmp/cc9lE3AW.s:26723: Error: symbol `.LCF72' is already defined
</code></pre>
<p>By specifying the --disable-pie option to configure, I succeed in bulding Ruby.</p>
<p>Interestingly, the build succeeds on the Ruby CI environment for PPC Linux, which is using gcc 4.7.2, so this might be a bug in gcc 4.4.0. In any case, I suppose <code>__builtin_setjmp</code> and <code>__builtin_longjmp</code> are undocumented functions of gcc (aren't they?), so we should be careful to use them. I hope this problem is avoided on the Ruby side even if this is a bug in gcc 4.4.0 on PPC Linux.</p>
<p>How about specifying -fPIE (unless --disable-pie is specified) when checking <code>__builtin_setjmp</code> and <code>__builtin_longjmp</code> in the configure script?</p> Ruby master - Bug #9666 (Closed): Segmentation fault while printing out C level backtrace informa...https://bugs.ruby-lang.org/issues/96662014-03-24T07:33:33ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>This might be related to [Bug <a class="issue tracker-1 status-5 priority-4 priority-default closed" title="Bug: Segmentation fault while printing out C level backtrace information (Closed)" href="https://bugs.ruby-lang.org/issues/9654">#9654</a>], but when $0 is set, a segmentation fault happens while printing out C-level backtrace. Due to this issue, <code>TestRubyOptions#test_segv_setproctitle</code> fails in my environment (ppc64 linux).</p>
<pre><code>ruby -e '$0="foo.rb"; Process.kill :SEGV, $$'
-e:1: [BUG] Segmentation fault at 0x001f80
ruby 2.2.0dev (2014-03-24) [powerpc64-linux]
-- Control frame information -----------------------------------------------
c:0003 p:---- s:0009 e:000008 CFUNC :kill
c:0002 p:0021 s:0004 E:0006f4 EVAL -e:1 [FINISH]
c:0001 p:0000 s:0002 E:000cd4 TOP [FINISH]
-- Ruby level backtrace information ----------------------------------------
-e:1:in `<main>'
-e:1:in `kill'
-- C level backtrace information -------------------------------------------
foo.rb [0x20774264]
foo.rb [0x207e250c]
foo.rb(rb_bug+0xc4) [0x207e2844]
foo.rb [0x206e64f0]
(__kernel_sigtramp_rt32+0x0) [0x100360]
foo.rb [0x20782ee8]
foo.rb(rb_f_kill+0x98) [0x206e74f8]
foo.rb [0x2075294c]
foo.rb [0x2075c5ac]
foo.rb [0x20771c60]
foo.rb [0x207699a8]
foo.rb [0x2076d8c8]
foo.rb(rb_iseq_eval_main+0x2f8) [0x2076def8]
foo.rb [0x20611884]
foo.rb(ruby_run_node+0xa4) [0x206136c4]
foo.rb [0x2060f77c]
/lib/libc.so.6(Segmentation fault
</code></pre>
<p>Here is the stack trace at the second segmentation fault.</p>
<pre><code>(gdb) bt
#0 0x2030a994 in strlen () from /lib/libc.so.6
#1 0x2085ce70 in kvprintf (fmt=0x208f0c45 "+0x%lx) [0x%lx] %s/%s:%d\n")
at addr2line.c:1014
#2 kprintf (fmt=0x208f0c45 "+0x%lx) [0x%lx] %s/%s:%d\n") at addr2line.c:776
#3 0x2085e8d8 in rb_dump_backtrace_with_lines (num_traces=18,
traces=0x2096790c, syms=0x20c27190) at addr2line.c:678
#4 0x2084428c in rb_print_backtrace () at vm_dump.c:690
#5 rb_vm_bugreport () at vm_dump.c:825
#6 0x208b250c in report_bug (file=<value optimized out>,
line=<value optimized out>, fmt=0x208e88dc "Segmentation fault at %p",
args=0x209d0034) at error.c:312
#7 0x208b2844 in rb_bug (fmt=0x208e88dc "Segmentation fault at %p")
at error.c:339
#8 0x207b64f0 in sigsegv (sig=<value optimized out>, info=0x209d00c0,
ctx=<value optimized out>) at signal.c:704
#9 <signal handler called>
#10 0x202b674c in kill () from /lib/libc.so.6
#11 0x20852ef4 in ruby_kill (pid=<value optimized out>,
sig=<value optimized out>) at thread.c:5185
<<<<< snip >>>>>
</code></pre>
<p>Again, line->sname points to some out-of-range address.</p> Ruby master - Bug #9654 (Closed): Segmentation fault while printing out C level backtrace informa...https://bugs.ruby-lang.org/issues/96542014-03-20T01:59:51ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>When SIGSEGV happens, C level backtrace information should be printed out, but the printing-out itself causes another segmentation fault.</p>
<pre><code>$ ./ruby -e 'Process.kill :SEGV, $$'
-e:1: [BUG] Segmentation fault at 0x00584f
ruby 2.2.0dev (2014-03-19) [powerpc64-linux]
-- Control frame information -----------------------------------------------
c:0003 p:---- s:0009 e:000008 CFUNC :kill
c:0002 p:0015 s:0004 E:00153c EVAL -e:1 [FINISH]
c:0001 p:0000 s:0002 E:002574 TOP [FINISH]
-- Ruby level backtrace information ----------------------------------------
-e:1:in `<main>'
-e:1:in `kill'
-- C level backtrace information -------------------------------------------
./ruby(Segmentation fault
</code></pre>
<p>This second segmentation fault happens at the following stack context.</p>
<pre><code>(gdb) bt
#0 0x201ba994 in strlen () from /lib/libc.so.6
#1 0x2070cbe0 in kvprintf (fmt=0x207a097d "+0x%lx) [0x%lx] %s:%d\n")
at addr2line.c:1009
#2 kprintf (fmt=0x207a097d "+0x%lx) [0x%lx] %s:%d\n") at addr2line.c:771
#3 0x2070e4f8 in rb_dump_backtrace_with_lines (num_traces=18,
traces=0x2081762c, syms=0x20a7d720) at addr2line.c:677
#4 0x206f3ffc in rb_print_backtrace () at vm_dump.c:690
#5 rb_vm_bugreport () at vm_dump.c:825
#6 0x207621ac in report_bug (file=<value optimized out>,
line=<value optimized out>, fmt=0x2079857c "Segmentation fault at %p",
args=0x2085f864) at error.c:312
#7 0x207624e4 in rb_bug (fmt=0x2079857c "Segmentation fault at %p")
at error.c:339
#8 0x206664e0 in sigsegv (sig=<value optimized out>, info=0x2085f8f0,
ctx=<value optimized out>) at signal.c:704
#9 <signal handler called>
#10 0x2016674c in kill () from /lib/libc.so.6
#11 0x20702c64 in ruby_kill (pid=<value optimized out>,
sig=<value optimized out>) at thread.c:5185
<<<<< snip >>>>>
</code></pre>
<p>This error began to occur after this change:<br>
<a href="http://www.rubyist.net/~kanemoto/chkbuild/plinux/ruby-trunk/log/20140314T070002Z.diff.html.gz" class="external">http://www.rubyist.net/~kanemoto/chkbuild/plinux/ruby-trunk/log/20140314T070002Z.diff.html.gz</a><br>
Due to this error, <code>TestBugReporter#test_bug_reporter_add</code> fails on ppc64 GNU/Linux.<br>
My guess is that the changes in addr2line.c are doing something, but I am not sure.</p>
<p>The second segmentation fault is caused because <code>line->sname</code> points to out-of-range memory.<br>
Tracing <code>rb_dump_backtrace_with_lines()</code> and <code>fill_lines()</code>, I found the <code>sname</code> entry was first set correctly by reading the <code>./ruby</code> file, but it was later overwritten by some incorrect information while reading the <code>/usr/lib/debug/lib/libc-2.5.so.debug</code> file.<br>
In <code>libc-2.5.so.debug</code>, there seem to be several symbol table entries whose <code>st_size</code> is quite big (~1.5 GB), so those entries happen to cover all the addresses in <code>traces[]</code>, which results in overwritting <code>sname</code> at the line 584 of addr2line.c.<br>
I am not familiar with ELF, so I cannot track down further.<br>
Hope this report helps.</p> Ruby master - Bug #9600 (Closed): sysconf(_SC_GETGR_R_SIZE_MAX) is just a hint for getgrnam_r()https://bugs.ruby-lang.org/issues/96002014-03-06T07:15:44ZReiOdaira (Rei Odaira)Rei.Odaira@gmail.com
<p>When there is a group that has a lot of members, TestProcess#test_execopts_gid fails. Following is a more simple example:</p>
<pre><code>$ ruby -e 'system("true", gid: "largegroup")'
-e:1:in `system': Numerical result out of range - getgrnam_r (Errno::ERANGE)
from -e:1:in `<main>'
</code></pre>
<p>This wrong exception happens because obj2gid() in process.c calls getgrnam_r() with a buffer that was allocated based on the size returned by sysconf(_SC_GETGR_R_SIZE_MAX). In Linux, sysconf(_SC_GETGR_R_SIZE_MAX) returns 1024, but actually this value is just a hint, so obj2gid() should gradually extend the buffer until getgrnam_r() no longer throws ERANGE.</p>
<p>The same issue was reported in the following page:<br>
<a href="http://tomlee.co/2012/10/problems-with-large-linux-unix-groups-and-getgrgid_r-getgrnam_r/" class="external">http://tomlee.co/2012/10/problems-with-large-linux-unix-groups-and-getgrgid_r-getgrnam_r/</a></p>