From: "Adam P. Jenkins" <ajenkins@...>
Date: 2005-05-18T06:25:31+09:00
Subject: Re: Rails on Altix ia64

Adam P. Jenkins wrote:
> Nakada, Nobuyoshi wrote:
> 
>> Hi,
>>
>> At Tue, 17 May 2005 09:55:30 +0900,
>> Adam P. Jenkins wrote in [ruby-talk:142863]:
>>
>>> Has anyone successfully run a Rails application on an Altix, or other
>>> ia64 machine?  I'm getting a segmentation fault in gc.c.  More info 
>>> below.
>>
>>
>>
>> Some bugs about GC on IA64 have been fixed since 1.8.2 release.  Try
>> 1.8.3 preview1.
>>
> 
> Thank you for your quick response.  I tried 1.8.3 preview1, and get the 
> same error.  When it happens, in gc_mark, ptr is always == 8.  The 
> function tries to interpret it as a pointer and dereference it. Here's 
> the result of trying my rails app with 1.8.3:
> 
> Start webrick:
> 
> $ script/server
> => Rails application started on http://0.0.0.0:3000
> [2005-05-16 22:37:33] INFO  WEBrick 1.3.1
> [2005-05-16 22:37:33] INFO  ruby 1.8.3 (2005-05-12) [ia64-linux]
> [2005-05-16 22:37:33] INFO  WEBrick::HTTPServer#start: pid=16740 port=3000
> 
> 
> Make a request from my browser, and webrick says:
> 
> /home/ajenkins/deploy/lib/ruby/1.8/timeout.rb:41: [BUG] Segmentation fault
> ruby 1.8.3 (2005-05-12) [ia64-linux]
> 
> Aborted (core dumped)

I was able to work around the problem by using a version of Ruby
compiled on an ia32 machine.  I just compiled Ruby on a ia32 running
Fedora Core 3, and transfered it to the Altix.  Now my Rails app runs
fine on the Altix, albeit much slower than with the natively compiled
Ruby.  This is a satisfactory workaround for me for now.

Before realizing I could work around the problem this way, I discovered
some more information about the problem which may be of interest to the
Ruby developers.  First of all, to reproduce the problem: (I'm using the
ruby-1.8.3-preview1 tarball.

# Build Ruby on the Altix
$ uname -a
Linux isc-altix 2.4.21-sgi304r1 #1 SMP Sat Jan 29 22:43:29 PST 2005 ia64
ia64 ia64 GNU/Linux
$ cd ruby-1.8.3
$ env CFLAGS='-O0 -g' ./configure --prefix=$DEPLOYDIR
$ make
$ make test
test succeeded
$ make install
$ PATH=$DEPLOYDIR/bin:$PATH

# Install Gem
$ cd ../rubygems-0.8.10
$ ruby setup.rb

# Install Rails
$ gem install --no-rdoc --include-dependencies rails

# Create a test rails app
$ cd ~/
$ rails testapp

# Run the app

$ testapp/script/server
=> Rails application started on http://0.0.0.0:3000
[2005-05-17 15:40:02] INFO  WEBrick 1.3.1
[2005-05-17 15:40:02] INFO  ruby 1.8.3 (2005-05-12) [ia64-linux]
[2005-05-17 15:40:02] INFO  WEBrick::HTTPServer#start: pid=4836 port=3000


Make a request to http://localhost:300 from a browser, and webrick outputs:

/home/ajenkins/deploy/lib/ruby/1.8/timeout.rb:41: [BUG] Segmentation fault
ruby 1.8.3 (2005-05-12) [ia64-linux]

Aborted

The code at timeout.rb:41 is a call to Thread.start.  I tried modifying
timeout to not spawn a thread, and then I'd get segfaults elsewhere,
always at a call to Thread.start.  So it seems to have something to do
with threading, since single threaded code seems to work fine.  When I
look at the core dumps, the segfault is always in gc_mark(), at
gc.c:715.  The ptr parameter to gc_mark always has the value 8.  gc_mark
tries to treat this as a pointer, and gets a segfault.  I didn't
understand the code in gc.c enough to get much farther in figuring out
how this value got there.

The start of gc_mark() looks like this:

void
gc_mark(ptr, lev)
     VALUE ptr;
     int lev;
{
     register RVALUE *obj;

     obj = RANY(ptr);
     if (rb_special_const_p(ptr)) return; /* special const not marked */
     if (obj->as.basic.flags == 0) return;       /* free cell */

The call to rb_special_const_p returns true if either of the bottom two
bits of ptr are set.  The code above seems to assume that if the bottom
two bits are cleared, then ptr is really a pointer value.  So when
gc_mark is called with the value 8 for its ptr parameter, it goes on to
execute the next line, which dereferences obj, and causes a segfault.

Hope this helps a little.
Adam