[#25272] [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Yui NARUSE <redmine@...>

Feature #2032: Change the license to "GPLv2+ or Ruby's original".

51 messages 2009/09/02
[#25368] [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Kazuhiko Shiozaki <redmine@...> 2009/09/04

Issue #2032 has been updated by Kazuhiko Shiozaki.

[#25461] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Gregory Brown <gregory.t.brown@...> 2009/09/07

On Fri, Sep 4, 2009 at 1:10 PM, Kazuhiko Shiozaki<redmine@ruby-lang.org> wrote:

[#25463] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Yukihiro Matsumoto <matz@...> 2009/09/08

Hi,

[#30610] [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Shyouhei Urabe <redmine@...> 2010/06/06

Issue #2032 has been updated by Shyouhei Urabe.

[#30611] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Yusuke ENDOH <mame@...> 2010/06/06

Hi,

[#30614] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Urabe Shyouhei <shyouhei@...> 2010/06/06

> To avoid enbugging a new bug, we must choose the another solutions.

[#30616] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Yusuke ENDOH <mame@...> 2010/06/06

2010/6/6 Urabe Shyouhei <shyouhei@ruby-lang.org>:

[#30652] Re: [Feature #2032] Change the license to "GPLv2+ or Ruby's original". — Urabe Shyouhei <shyouhei@...> 2010/06/08

(2010/06/06 20:27), Yusuke ENDOH wrote:

[#25285] [Feature #2033] Move Core Development to Git — Run Paint Run Run <redmine@...>

Feature #2033: Move Core Development to Git

75 messages 2009/09/02
[#25299] Re: [Feature #2033] Move Core Development to Git — Eric Hodel <drbrain@...7.net> 2009/09/02

On Sep 2, 2009, at 11:19, Run Paint Run Run wrote:

[#25290] [Feature #2033] Move Core Development to Git — Yui NARUSE <redmine@...> 2009/09/02

Issue #2033 has been updated by Yui NARUSE.

[#25297] Re: [Feature #2033] Move Core Development to Git — Jon <jon.forums@...> 2009/09/02

> Some commiter of Ruby live on Windows.

[#25342] Re: [Feature #2033] Move Core Development to Git — Urabe Shyouhei <shyouhei@...> 2009/09/03

Jon wrote:

[#25343] Re: [Feature #2033] Move Core Development to Git — Michal Suchanek <hramrach@...> 2009/09/03

2009/9/4 Urabe Shyouhei <shyouhei@ruby-lang.org>:

[#25345] Re: [Feature #2033] Move Core Development to Git — Urabe Shyouhei <shyouhei@...> 2009/09/03

Michal Suchanek wrote:

[#25306] [Feature #2034] Consider the ICU Library for Improving and Expanding Unicode Support — Run Paint Run Run <redmine@...>

Feature #2034: Consider the ICU Library for Improving and Expanding Unicode Support

16 messages 2009/09/03

[#25394] Unmaintained code (Was: Move Core Development to Git) — Eric Hodel <drbrain@...7.net>

On Sep 4, 2009, at 02:16, Urabe Shyouhei wrote:

10 messages 2009/09/05

[#25420] [Bug #2054] Onigurma Isn't Documented — Run Paint Run Run <redmine@...>

Bug #2054: Onigurma Isn't Documented

17 messages 2009/09/05

[#25442] turning off indentation warnings — Aaron Patterson <aaron@...>

Is there a way in 1.9 to turn off only indentation warnings? I like

19 messages 2009/09/06
[#25510] Re: turning off indentation warnings — Nobuyoshi Nakada <nobu@...> 2009/09/10

Hi,

[#25511] [Bug #2079] win32ole's OLEGEN does not create all classes needed when a TLB has more than one class defined — Bruno Antunes <redmine@...>

Bug #2079: win32ole's OLEGEN does not create all classes needed when a TLB has more than one class defined

18 messages 2009/09/10

[#25644] [Bug #2121] mathn/rational destroys Fixnum#/, Fixnum#quo and Bignum#/, Bignum#quo — Charles Nutter <redmine@...>

Bug #2121: mathn/rational destroys Fixnum#/, Fixnum#quo and Bignum#/, Bignum#quo

12 messages 2009/09/19

[#25709] [Bug #2131] f(not x) => syntax error — "James M. Lawrence" <redmine@...>

Bug #2131: f(not x) => syntax error

16 messages 2009/09/22

[#25769] A challenge: Enumerator#next in JRuby — Charles Oliver Nutter <headius@...>

I have a challenge for anyone who wants to discuss, propose

25 messages 2009/09/25
[#25782] Re: A challenge: Enumerator#next in JRuby — Tanaka Akira <akr@...> 2009/09/26

In article <f04d2210909251312q46bd51c0teacc4b0a8c417f0c@mail.gmail.com>,

[#25820] [Feature #2152] Split functionality of Float#inspect and Float#to_s — Roger Pack <redmine@...>

Feature #2152: Split functionality of Float#inspect and Float#to_s

32 messages 2009/09/28

[#25853] [Bug #2160] JSON can't parse input where top-level object is a string — caleb clausen <redmine@...>

Bug #2160: JSON can't parse input where top-level object is a string

11 messages 2009/09/29

[ruby-core:25714] [Bug #2133] Segfault When Eval'ing Large Hash Literals

From: Run Paint Run Run <redmine@...>
Date: 2009-09-22 15:22:22 UTC
List: ruby-core #25714
Bug #2133: Segfault When Eval'ing Large Hash Literals
http://redmine.ruby-lang.org/issues/show/2133

Author: Run Paint Run Run
Status: Open, Priority: Normal
Category: core, Target version: 1.9.2
ruby -v: ruby 1.9.2dev (2009-09-11) [i686-linux]

I can reproduce a segfault on ruby 1.9.2dev (2009-09-11) [i686-linux] by creating a hash with many thousands of keys, then eval'ing the result.

  $ cat /tmp/large-hash.rb
  hash = {}
  IO.foreach('/usr/share/dict/words') do |line|
    hash[line] = line.size
  end
  p "Hashed #{hash.keys.size} keys"
  eval <<EOF
  class C
    @@h = #{hash.inspect}
  end
  EOF

  $ ruby /tmp/large-hash.rb
  "Hashed 638311 keys"
  (eval):2: [BUG] Segmentation fault
  ruby 1.9.2dev (2009-09-11) [i686-linux]

  -- control frame ----------
  c:0007 p:261966 s:302922756 b:0017 l:000016 d:000016 CLASS  (eval):2
  c:0006 p:0009 s:0015 b:0015 l:00080c d:000014 EVAL   (eval):1
  c:0005 p:---- s:0013 b:0013 l:000012 d:000012 FINISH
  c:0004 p:---- s:0011 b:0011 l:000010 d:000010 CFUNC  :eval
  c:0003 p:0078 s:0007 b:0007 l:00080c d:000ea8 EVAL   /tmp/large-hash.rb:6
  c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH
  c:0001 p:0000 s:0002 b:0002 l:00080c d:00080c TOP   
  ---------------------------
  /tmp/large-hash.rb:6:in `<main>'
  /tmp/large-hash.rb:6:in `eval'
  (eval):1:in `<main>'
  (eval):2:in `<class:C>'

  -- C level backtrace information -------------------------------------------
  ruby(rb_vm_bugreport+0xb5) [0x8167535]
  ruby [0x81a3fcb]
  ruby(rb_bug+0x28) [0x81a4058]
  ruby [0x80fb585]
  [0xb7f29410]
  ruby [0x815e884]
  ruby [0x815f5c0]
  ruby(rb_f_eval+0xe1) [0x815fbd1]
  ruby [0x81537cd]
  ruby [0x8153919]
  ruby [0x8165555]
  ruby [0x81595fd]
  ruby [0x815e884]
  ruby(rb_iseq_eval_main+0x1a3) [0x815eb73]
  ruby(ruby_exec_node+0x97) [0x805d797]
  ruby(ruby_run_node+0x46) [0x805f0d6]
  ruby(main+0x60) [0x805cbb0]
  /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7d49775]
  ruby [0x805cab1]

  [NOTE]
  You may have encountered a bug in the Ruby interpreter or extension libraries.
  Bug reports are welcome.
  For details: http://www.ruby-lang.org/bugreport.html

(My dictionary is 6.5MB, so I haven't attached it.)

The same problem is encountered when the contents of the heredoc is piped to a file which is then require'd, also.

It is relevant that the hash is instantiated inside of a class; in the example below a segfault does not occur:
  
  $ cat /tmp/large-hash.rb
  hash = {}
  IO.foreach('/usr/share/dict/words') do |line|
    hash[line] = line.size
  end
  p "Hashed #{hash.keys.size} keys"
  eval "h = #{hash.inspect}"

  $ ruby /tmp/large-hash.rb
  "Hashed 638311 keys"
  (eval):0:in `<main>': stack level too deep (SystemStackError)
	from /tmp/large-hash.rb:6:in `eval'
	from /tmp/large-hash.rb:6:in `<main>'


----------------------------------------
http://redmine.ruby-lang.org

In This Thread

Prev Next