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

[ruby-core:115373] [Ruby master Bug#8444] Regexp vars $~ and friends are not thread local
by jemmai (Jemma Issroff) 13 Nov '23

13 Nov '23

Issue #8444 has been updated by jemmai (Jemma Issroff). Status changed from Open to Closed This bug is not reproducible for Ruby > 2.7.5. It has clearly been fixed, closing! ---------------------------------------- Bug #8444: Regexp vars $~ and friends are not thread local https://bugs.ruby-lang.org/issues/8444#change-105305 * Author: jamespharaoh (James Pharaoh) * Status: Closed * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: trunk ---------------------------------------- =begin In the docs for the Regexp special variables, $~ and friends, it says "These global variables are thread-local and method-local variables". However the following gives an unexpected result: def get_proc proc do |str| str =~ /(.+)/ sleep 0.1 puts "got #{$1} from #{str}\n" end end proc = get_proc t1 = Thread.new { proc.call "abc" } t2 = Thread.new { proc.call "def" } t1.join t2.join This outputs the following: got abc from abc got abc from def The expected result is of course: got abc from abc got def from def Clearly the variables are being scoped to the get_proc method and are being shared by both threads. This runs contrary to the documentation and also to expectations. This behaviour should either be changed, or the documentation updated to reflect the actual behaviour. Interestingly, the following does work as expected: proc = proc do |str| str =~ /(.+)/ sleep 0.1 puts "got #{$1} from #{str}\n" end t1 = Thread.new { proc.call "abc" } t2 = Thread.new { proc.call "def" } t1.join t2.join =end -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115372] [Ruby master Bug#9010] ./configure --prefix= cannot handle directories with spaces
by fcheung (Frederick Cheung) 13 Nov '23

13 Nov '23

Issue #9010 has been updated by fcheung (Frederick Cheung). Still happening on master as b1f345b1 when building on macos: ``` ../configure --prefix="${HOME}/dir with space/.rubies/ruby-master" make install ``` produces ``` ... linking shared-library libruby.3.3.dylib clang: error: no such file or directory: 'with' clang: error: no such file or directory: 'space/.rubies/ruby-master/lib/libruby.3.3.dylib' make: *** [libruby.3.3.dylib] Error 1 ``` ---------------------------------------- Bug #9010: ./configure --prefix= cannot handle directories with spaces https://bugs.ruby-lang.org/issues/9010#change-105303 * Author: postmodern (Hal Brodigan) * Status: Assigned * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * ruby -v: trunk ---------------------------------------- It appears that the linking task fails when the --prefix value contains spaces. Steps to Reproduce: 1. ./configure --prefix="$HOME/foo bar" 2. make Expected Result: success Actual Result: make[2]: Entering directory `/home/hal/src/ruby-2.0.0-p247' linking ruby gcc: error: bar/lib: No such file or directory gcc: error: bar/lib: No such file or directory make[2]: *** [ruby] Error 1 make[2]: Leaving directory `/home/hal/src/ruby-2.0.0-p247' make[1]: *** [all] Error 2 make[1]: Leaving directory `/home/hal/src/ruby-2.0.0-p247' make: *** [build-ext] Error 2 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115371] [Ruby master Bug#11514] AIX6.1 - Ruby 2.2.3 - Segmentation fault in :byteslice
by jemmai (Jemma Issroff) 13 Nov '23

13 Nov '23

Issue #11514 has been updated by jemmai (Jemma Issroff). Status changed from Open to Closed Closing because AIX6.1 and Ruby 2.2 are both EOL, as per @jarrodreyesdev's comment https://bugs.ruby-lang.org/issues/11514#note-10 ---------------------------------------- Bug #11514: AIX6.1 - Ruby 2.2.3 - Segmentation fault in :byteslice https://bugs.ruby-lang.org/issues/11514#change-105302 * Author: TRex58 (Tony Reix) * Status: Closed * Priority: Normal * ruby -v: ?? ruby 2.1.1p76 (2014-02-24 revision 45161) [powerpc-aix6.1.0.0] ---------------------------------------- Testing Ruby 2.2.3 on AIX6.1 built with xlc (same with gcc) leads to a reproducible crash. See complete trace in attached file. Ruby version is: RUBY_PROGRAM_VERSION=2.2.3 . ~~~ # gmake V=1 test-all ... objcopy -w -L 'Init_*' -L '*_threadptr_*' libruby.so.2.2.0 : /usr/vac/bin/xlc_r -g -qinfo=por -L. -bE:ruby.imp -brtl -blibpath:NONE/lib:/usr/lib:/lib main.o -L/usr/local/lib -lruby -lpthread -lgmp -ldl -lcrypt -lm -o ruby : gmake[2]: Leaving directory `/opt/freeware/src/packages/BUILD/ruby-2.2.3' gmake[1]: Leaving directory `/opt/freeware/src/packages/BUILD/ruby-2.2.3' Generating RDoc documentation ./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems "./bin/rdoc" --root "." --page-dir "./doc" --encoding=UTF-8 --no-force-update --all --ri --op ".ext/rdoc" --debug "." Parsing sources... 100% [967/967] vsnprintf.c Generating RI format into /opt/freeware/src/packages/BUILD/ruby-2.2.3/.ext/rdoc... BEFORE @generator.generate in lib/rdoc/rdoc.rb /opt/freeware/src/packages/BUILD/ruby-2.2.3/lib/rdoc/markup/parser.rb:331: [BUG] **Segmentation fault** at 0x000004 ruby 2.2.3p173 (2015-08-18 revision 51636) [powerpc-aix6.1.9.0] -- Control frame information ----------------------------------------------- c:0025 p:---- s:0126 e:000125 CFUNC **:byteslice** c:0024 p:0019 s:0121 e:000120 METHOD /opt/freeware/src/packages/BUILD/ruby-2.2.3/lib/rdoc/markup/parser.rb:331 c:0023 p:0009 s:0116 e:000115 METHOD /opt/freeware/src/packages/BUILD/ruby-2.2.3/lib/rdoc/markup/parser.rb:547 c:0022 p:0438 s:0111 e:000108 METHOD /opt/freeware/src/packages/BUILD/ruby-2.2.3/lib/rdoc/markup/parser.rb:501 c:0021 p:0017 s:0099 e:000098 METHOD /opt/freeware/src/packages/BUILD/ruby-2.2.3/lib/rdoc/markup/parser.rb:62 c:0020 p:0019 s:0093 e:000092 METHOD /opt/freeware/src/packages/BUILD/ruby-2.2.3/lib/rdoc/markup.rb:748 ... gmake: *** [rdoc] IOT/Abort trap (core dumped) # ll ./.ext/rdoc/core -rw------- 1 root system 269015892 Sep 8 14:08 ./.ext/rdoc/core # dbx ./ruby ./.ext/rdoc/core IOT/Abort trap in pthread_kill at 0xd051ceb4 ($t1) 0xd051ceb4 (pthread_kill+0xb4) 80410014 lwz r2,0x14(r1) (dbx) where pthread_kill(??, ??) at 0xd051ceb4 _p_raise(??) at 0xd051c2e8 raise.raise(??) at 0xd011f8a0 abort() at 0xd01a9a04 die(), line 395 in "error.c" libdebug assertion "(framep->getGpr(STKP, &addr) == DB_SUCCESS && *nextStkpp == addr)" failed at line 1299 in file ../../../../../../../../../../../src/bos/usr/ccs/lib/libdbx/libdebug/modules/stackdebug/POWER/stackdb_FrameProgress.C rb_bug_context(ctx = 0x200f83b0, fmt = "Segmentation fault at %p", ... = 0x4, 0xd052f200, 0x0, 0x117100f5, 0x117100f5, 0x200f7f28), line 427 in "error.c" sigsegv(sig = 11, info = 0x200f863c, ctx = 0x200f83b0), line 879 in "signal.c" ---Files-------------------------------- RubyCore (15.8 KB) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115370] [Ruby master Bug#8444] Regexp vars $~ and friends are not thread local
by katie.caballero2013＠gmail.com (Katie Caballero) 13 Nov '23

13 Nov '23

Issue #8444 has been updated by katie.caballero2013(a)gmail.com (Katie Caballero). RubyConf Hack Day: suggest to close ---------------------------------------- Bug #8444: Regexp vars $~ and friends are not thread local https://bugs.ruby-lang.org/issues/8444#change-105300 * Author: jamespharaoh (James Pharaoh) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * ruby -v: trunk ---------------------------------------- =begin In the docs for the Regexp special variables, $~ and friends, it says "These global variables are thread-local and method-local variables". However the following gives an unexpected result: def get_proc proc do |str| str =~ /(.+)/ sleep 0.1 puts "got #{$1} from #{str}\n" end end proc = get_proc t1 = Thread.new { proc.call "abc" } t2 = Thread.new { proc.call "def" } t1.join t2.join This outputs the following: got abc from abc got abc from def The expected result is of course: got abc from abc got def from def Clearly the variables are being scoped to the get_proc method and are being shared by both threads. This runs contrary to the documentation and also to expectations. This behaviour should either be changed, or the documentation updated to reflect the actual behaviour. Interestingly, the following does work as expected: proc = proc do |str| str =~ /(.+)/ sleep 0.1 puts "got #{$1} from #{str}\n" end t1 = Thread.new { proc.call "abc" } t2 = Thread.new { proc.call "def" } t1.join t2.join =end -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115369] [Ruby master Bug#11808] Different behavior between Enumerable#grep and Array#grep
by noelrap (Noel Rappin) 13 Nov '23

13 Nov '23

Issue #11808 has been updated by noelrap (Noel Rappin). This appears to be fixed in 3.3.0dev as of Nov 2023, ``` ruby irb(main):001* class Test irb(main):002* include Enumerable irb(main):003* def each irb(main):004* return enum_for(:each) unless block_given? irb(main):005* yield "Hello" irb(main):006* yield "World" irb(main):007* end irb(main):008> end => :each irb(main):009> irb(main):010> enum = Test.new => #<Test:0x0000000102ba5038> irb(main):011> array = ["Hello", "World"] => ["Hello", "World"] irb(main):012> irb(main):013> enum.grep(/^(.)/) {$1} => ["H", "W"] ``` However, it was still broken in 3.2.2. It's not clear to me when the behavior changed. ---------------------------------------- Bug #11808: Different behavior between Enumerable#grep and Array#grep https://bugs.ruby-lang.org/issues/11808#change-105298 * Author: BenOlive (Ben Olive) * Status: Open * Priority: Normal * Assignee: ko1 (Koichi Sasada) * Backport: 2.5: UNKNOWN, 2.6: UNKNOWN ---------------------------------------- Regex special global variables are available within the block for `Array#grep`, but are nil within the block for `Enumerable#grep`. Here is an example that explains it better: ~~~ruby class Test include Enumerable def each return enum_for(:each) unless block_given? yield "Hello" yield "World" end end enum = Test.new array = ["Hello", "World"] enum.grep(/^(.)/) {$1} # => [nil, nil] array.grep(/^(.)/) {$1} # => ["H", "W"] ~~~ Tested on 2.0.0, 2.1.5, & 2.2.2 -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115368] [Ruby master Bug#6360] Debug information build even without requesting it
by pcai (Peter Cai) 13 Nov '23

13 Nov '23

Issue #6360 has been updated by pcai (Peter Cai). This still seems to set -ggdb3 CFLAGS by default in master. Is this still considered a bug and if so, how should it be re-enabled? ---------------------------------------- Bug #6360: Debug information build even without requesting it https://bugs.ruby-lang.org/issues/6360#change-105297 * Author: luislavena (Luis Lavena) * Status: Assigned * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * ruby -v: 2.0.0 i386-mingw32 r35473 ---------------------------------------- Hello, While working on latest RubyInstaller release for 1.9.3-p194 our team detected a bigger shared library and import library being generated. After further inspection, we found this commit: https://github.com/ruby/ruby/commit/ffdaca1d748804f2b5ca2de612f17cf6c78d351b Backported r34840 into ruby_1_9_3 branch The above change added -ggdb to CFLAGS even when was not provided by debugflags configure option. The following is the comparison of "make" summary with and without the change: Current trunk: <pre> C:\Users\Luis\Projects\oss\ruby\build32>make CC = gcc LD = ld LDSHARED = gcc -shared CFLAGS = -O3 -fno-omit-frame-pointer -ggdb -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Werror=pointer-arith -Werror=write-strings -Werror=declaration-after-statement -Werror=implicit-function-declaration XCFLAGS = -include ruby/config.h -include ruby/missing.h -D_FORTIFY_SOURCE=2 -fno-strict-overflow -fvisibility=hidden -DRUBY_EXPORT CPPFLAGS = -DFD_SETSIZE=32767 -D_WIN32_WINNT=0x0501 -I. -I.ext/include/i386-mingw32 -I../include -I.. DLDFLAGS = -Wl,--enable-auto-image-base,--enable-auto-import -Wl,--out-implib=libmsvcrt-ruby200.dll.a msvcrt-ruby200.def -Wl,--stack,0x00200000,--enable-auto-import SOLIBS = msvcrt-ruby200.res.o -lshell32 -lws2_32 -limagehlp </pre> Reverting r34840: <pre> C:\Users\Luis\Projects\oss\ruby\build32>make CC = gcc LD = ld LDSHARED = gcc -shared -s CFLAGS = -O3 -fno-omit-frame-pointer -g -Wall -Wextra -Wno-unused-parameter -Wno-parentheses -Wno-long-long -Wno-missing-field-initializers -Wunused-variable -Werror=pointer-arith -Werror=write-strings -Werror=declaration-after-statement -Werror=implicit-function-declaration XCFLAGS = -include ruby/config.h -include ruby/missing.h -D_FORTIFY_SOURCE=2 -fno-strict-overflow -fvisibility=hidden -DRUBY_EXPORT CPPFLAGS = -DFD_SETSIZE=32767 -D_WIN32_WINNT=0x0501 -I. -I.ext/include/i386-mingw32 -I../include -I.. DLDFLAGS = -Wl,--enable-auto-image-base,--enable-auto-import -Wl,--out-implib=libmsvcrt-ruby200.dll.a msvcrt-ruby200.def -Wl,--stack,0x00200000,--enable-auto-import SOLIBS = msvcrt-ruby200.res.o -lshell32 -lws2_32 -limagehlp </pre> Notice that -g changed into -ggdb instead. I think debug symbols shouldn't be compiled unless requested and this is a regression. -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115367] [Ruby master Bug#7968] Poor UDPSocket#send performance in ruby 2.0.0 on windows
by JesseJohnson (Jesse Johnson) 13 Nov '23

13 Nov '23

Issue #7968 has been updated by JesseJohnson (Jesse Johnson). Can anyone replicate this on Ruby 3 or later? ---------------------------------------- Bug #7968: Poor UDPSocket#send performance in ruby 2.0.0 on windows https://bugs.ruby-lang.org/issues/7968#change-105296 * Author: cs96and (Alan Davies) * Status: Assigned * Priority: Normal * Assignee: windows * ruby -v: ruby 2.0.0p0 (2013-02-24) [x64-mingw32] ---------------------------------------- I have noticed that the performance of UDPSocket#send on ruby 2.0.0 on windows is much poorer than that of 1.9.3 or 1.8.7. Running the attahced script on 2.0.0 gives the following... d:\scripts>bash -c "ruby --version" ruby 2.0.0p0 (2013-02-24) [x64-mingw32] d:\scripts>bash -c "time ruby socketsendtest.rb" real 0m2.572s user 0m0.000s sys 0m0.016s However, running the same test with 1.9.3 is much faster... d:\scripts>pik 193 d:\scripts>bash -c "ruby --version" ruby 1.9.3p374 (2013-01-15) [i386-mingw32] d:\scripts>bash -c "time ruby socketsendtest.rb" real 0m0.993s user 0m0.015s sys 0m0.016s Additionally, if I change the send call to a print (commented out in the script), then the performance is fine on 2.0.0.... d:\scripts>pik 200 d:\scripts>bash -c "ruby --version" ruby 2.0.0p0 (2013-02-24) [x64-mingw32] d:\scripts>bash -c "time ruby socketsendtest.rb" real 0m0.907s user 0m0.000s sys 0m0.015s What is send() doing that print() doesn't do that is causing the massive performance drop? Thanks Alan. ---Files-------------------------------- socketsendtest.rb (266 Bytes) -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115366] [Ruby master Bug#7964] Writing an ASCII-8BIT String to a StringIO created from a UTF-8 String
by madeline-hou (Madeline Hou) 13 Nov '23

13 Nov '23

Issue #7964 has been updated by madeline-hou (Madeline Hou). @naruse (Yui NARUSE) Like you said, the example comparisons aren't equal. I saw that the Feature #5677 that your linked to in your comment was rejected, would it be alright to close this issue? ---------------------------------------- Bug #7964: Writing an ASCII-8BIT String to a StringIO created from a UTF-8 String https://bugs.ruby-lang.org/issues/7964#change-105295 * Author: brixen (Brian Shirai) * Status: Assigned * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * ruby -v: ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-darwin10.8.0] ---------------------------------------- =begin In the following script, an ASCII-8BIT String is written to a StringIO created with a UTF-8 String without error. However, a << b or a + b will raise an exception, as will writing an ASCII-8BIT String to a File with UTF-8 external encoding. + $ cat file_enc.rb # encoding: utf-8 require 'stringio' a = "On a very cold morning, it was -8°F." b = a.dup.force_encoding "ascii-8bit" io = StringIO.new a io.write(b) p io.string.encoding File.open "data.txt", "w:utf-8" do |f| f.write a f.write b end + $ ruby2.0 -v file_enc.rb ruby 2.0.0p0 (2013-02-24 revision 39474) [x86_64-darwin10.8.0] #<Encoding:UTF-8> file_enc.rb:13:in `write': "\xC2" from ASCII-8BIT to UTF-8 (Encoding::UndefinedConversionError) from file_enc.rb:13:in `block in <main>' from file_enc.rb:11:in `open' from file_enc.rb:11:in `<main>' + $ ruby1.9.3 -v file_enc.rb ruby 1.9.3p327 (2012-11-10 revision 37606) [x86_64-darwin10.8.0] #<Encoding:UTF-8> file_enc.rb:13:in `write': "\xC2" from ASCII-8BIT to UTF-8 (Encoding::UndefinedConversionError) from file_enc.rb:13:in `block in <main>' from file_enc.rb:11:in `open' from file_enc.rb:11:in `<main>' =end -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115365] [Ruby master Bug#8299] Minor error in float parsing
by JesseJohnson (Jesse Johnson) 13 Nov '23

13 Nov '23

Issue #8299 has been updated by JesseJohnson (Jesse Johnson). I'm not able to replicate this in Ruby 2.6 or Ruby 3.2. Has this been fixed in the relevant compilers? If so can this bug be closed? ``` irb(main):001:0> RUBY_VERSION => "2.6.10" irb(main):002:0> -1.1505945E-5 => -1.1505945e-05 ``` ``` irb(main):001> RUBY_VERSION => "3.2.2" irb(main):002> -1.1505945E-5 => -1.1505945e-05 ``` ---------------------------------------- Bug #8299: Minor error in float parsing https://bugs.ruby-lang.org/issues/8299#change-105294 * Author: bobjalex (Bob Alexander) * Status: Assigned * Priority: Normal * Assignee: nobu (Nobuyoshi Nakada) * ruby -v: trunk ---------------------------------------- I encountered a float that either parses [slightly] differently (or converts to string differently) in Ruby than it does in Python or Java. This looks like a Ruby bug since the result "looks" incorrect. It is easily reproduced by entering the magic number (-1.1505945E-5) into irb. It behaves the same in 2.0 and 1.9. I'm using Windows. Below is an irb session that demonstrates. Also included are JRuby and Python trials that show better behavior. This issue is not causing me any problems, but just in case someone there is interested in looking into it... Bob >ruby -v ruby 2.0.0p0 (2013-02-24) [i386-mingw32] >irb irb(main):001:0> RUBY_VERSION => "2.0.0" irb(main):002:0> -1.1505945E-5 => -1.1505945000000001e-05 >ruby19 -v ruby 1.9.3p392 (2013-02-22) [i386-mingw32] >irb19 irb(main):001:0> RUBY_VERSION => "1.9.3" irb(main):002:0> -1.1505945E-5 => -1.1505945000000001e-05 irb(main):002:0> >jirb irb(main):001:0> -1.1505945E-5 => -1.1505945e-05 >python Python 2.7.4rc1 (default, Mar 24 2013, 14:34:32) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> -1.1505945E-5 -1.1505945e-05 >>> repr(-1.1505945E-5) '-1.1505945e-05' -- https://bugs.ruby-lang.org/

1 0

[ruby-core:115364] [Ruby master Bug#11514] AIX6.1 - Ruby 2.2.3 - Segmentation fault in :byteslice
by jarrodreyesdev (Jarrod Reyes) 13 Nov '23

13 Nov '23

Issue #11514 has been updated by jarrodreyesdev (Jarrod Reyes). AIX6.1 is deprecated: https://www.ibm.com/support/pages/tlsp-doc-number3035-support-lifecycle-not… Ruby 2.2 is end of life: https://www.ruby-lang.org/en/downloads/branches/ ---------------------------------------- Bug #11514: AIX6.1 - Ruby 2.2.3 - Segmentation fault in :byteslice https://bugs.ruby-lang.org/issues/11514#change-105293 * Author: TRex58 (Tony Reix) * Status: Open * Priority: Normal * ruby -v: ?? ruby 2.1.1p76 (2014-02-24 revision 45161) [powerpc-aix6.1.0.0] ---------------------------------------- Testing Ruby 2.2.3 on AIX6.1 built with xlc (same with gcc) leads to a reproducible crash. See complete trace in attached file. Ruby version is: RUBY_PROGRAM_VERSION=2.2.3 . ~~~ # gmake V=1 test-all ... objcopy -w -L 'Init_*' -L '*_threadptr_*' libruby.so.2.2.0 : /usr/vac/bin/xlc_r -g -qinfo=por -L. -bE:ruby.imp -brtl -blibpath:NONE/lib:/usr/lib:/lib main.o -L/usr/local/lib -lruby -lpthread -lgmp -ldl -lcrypt -lm -o ruby : gmake[2]: Leaving directory `/opt/freeware/src/packages/BUILD/ruby-2.2.3' gmake[1]: Leaving directory `/opt/freeware/src/packages/BUILD/ruby-2.2.3' Generating RDoc documentation ./miniruby -I./lib -I. -I.ext/common ./tool/runruby.rb --extout=.ext -- --disable-gems "./bin/rdoc" --root "." --page-dir "./doc" --encoding=UTF-8 --no-force-update --all --ri --op ".ext/rdoc" --debug "." Parsing sources... 100% [967/967] vsnprintf.c Generating RI format into /opt/freeware/src/packages/BUILD/ruby-2.2.3/.ext/rdoc... BEFORE @generator.generate in lib/rdoc/rdoc.rb /opt/freeware/src/packages/BUILD/ruby-2.2.3/lib/rdoc/markup/parser.rb:331: [BUG] **Segmentation fault** at 0x000004 ruby 2.2.3p173 (2015-08-18 revision 51636) [powerpc-aix6.1.9.0] -- Control frame information ----------------------------------------------- c:0025 p:---- s:0126 e:000125 CFUNC **:byteslice** c:0024 p:0019 s:0121 e:000120 METHOD /opt/freeware/src/packages/BUILD/ruby-2.2.3/lib/rdoc/markup/parser.rb:331 c:0023 p:0009 s:0116 e:000115 METHOD /opt/freeware/src/packages/BUILD/ruby-2.2.3/lib/rdoc/markup/parser.rb:547 c:0022 p:0438 s:0111 e:000108 METHOD /opt/freeware/src/packages/BUILD/ruby-2.2.3/lib/rdoc/markup/parser.rb:501 c:0021 p:0017 s:0099 e:000098 METHOD /opt/freeware/src/packages/BUILD/ruby-2.2.3/lib/rdoc/markup/parser.rb:62 c:0020 p:0019 s:0093 e:000092 METHOD /opt/freeware/src/packages/BUILD/ruby-2.2.3/lib/rdoc/markup.rb:748 ... gmake: *** [rdoc] IOT/Abort trap (core dumped) # ll ./.ext/rdoc/core -rw------- 1 root system 269015892 Sep 8 14:08 ./.ext/rdoc/core # dbx ./ruby ./.ext/rdoc/core IOT/Abort trap in pthread_kill at 0xd051ceb4 ($t1) 0xd051ceb4 (pthread_kill+0xb4) 80410014 lwz r2,0x14(r1) (dbx) where pthread_kill(??, ??) at 0xd051ceb4 _p_raise(??) at 0xd051c2e8 raise.raise(??) at 0xd011f8a0 abort() at 0xd01a9a04 die(), line 395 in "error.c" libdebug assertion "(framep->getGpr(STKP, &addr) == DB_SUCCESS && *nextStkpp == addr)" failed at line 1299 in file ../../../../../../../../../../../src/bos/usr/ccs/lib/libdbx/libdebug/modules/stackdebug/POWER/stackdb_FrameProgress.C rb_bug_context(ctx = 0x200f83b0, fmt = "Segmentation fault at %p", ... = 0x4, 0xd052f200, 0x0, 0x117100f5, 0x117100f5, 0x200f7f28), line 427 in "error.c" sigsegv(sig = 11, info = 0x200f863c, ctx = 0x200f83b0), line 879 in "signal.c" ---Files-------------------------------- RubyCore (15.8 KB) -- https://bugs.ruby-lang.org/

1 0