On 30-Nov-06, at 12:50 PM, Bob Hutchison wrote:

> A little more on this...
>
> On 30-Nov-06, at 10:36 AM, Bob Hutchison wrote:
>
>> Hi,
>>
>> I'm getting a 'Segmentation fault' in ruby 1.8.5 running on debian  
>> in a Xen VPS. The same code running on OS X and a different  
>> version of linux has no problems.
>>
>> The process to get this is maybe a little strange.
>>
>> 1) read a large file into a string (1.3MB)
>> 2) eval the string (the string is a single ruby proc definition  
>> that when called will build an object structure in memory)
>> 3) call the proc --> Segmentation fault *very* soon after
>>

[snip]

>
> So maybe this is reproducible?? Well, so it is. If I run this script:
>
> module SomeModule
>   def initialize
>     @@proc = nil
>   end
>
>   def SomeModule.build
>     if @@proc then
>       result = @@proc.call
>       @@proc = nil
>       return result
>     end
>   end
> end
>
> N = 5000
>
> the_string = ""
>
> the_string << "module SomeModule\n"
> the_string << "  @@proc = Proc.new {\n"
> the_string << "    thing = []\n"
>
> N.times do | i |
>   the_string <<  "    v#{i} = [#{i}]\n"
> end
>
> N.times do | i |
>   the_string <<  "    thing << v#{i}\n"
> end
>
> the_string << "    thing\n"
> the_string << "  } #proc\n"
> the_string << "end\n"
>
> puts("the_string length: #{the_string.length}")
> eval(the_string, nil, "ruby_definition", 0)
> SomeModule.build
>
>
> It will fail on the one linux box, run on the other, and run on OS  
> X. With a little binary search, the smallest N that causes the  
> segfault is 3024 (3023 works).
>

So, to increase the strangeness a bit... if I run this from within  
vim (i.e. using ":!ruby crash.rb") it works for some pretty big Ns.

Sigh.

Cheers,
Bob

----
Bob Hutchison                  -- blogs at <http://www.recursive.ca/ 
hutch/>
Recursive Design Inc.          -- <http://www.recursive.ca/>
Raconteur                      -- <http://www.raconteur.info/>
xampl for Ruby                 -- <http://rubyforge.org/projects/xampl/>