Ruby corrupts after a period of time

C

Chip Burke

I have recently upgraded from Ruby 1.8.7 to 1.9.2p180 on Fedora. After a
period of time, a day perhaps, the installation goes corrupt. It works
perfectly fine initially then everything fails. I am rolling this from
source with typical ./configure/make/make install type process. A few
examples:

#irb
<internal:lib/rubygems/custom_require>:29:in `require': closed stream
(IOError)
from <internal:lib/rubygems/custom_require>:29:in `require'
from /usr/lib/ruby/1.9.1/irb.rb:13:in `<top (required)>'
from <internal:lib/rubygems/custom_require>:29:in `require'
from <internal:lib/rubygems/custom_require>:29:in `require'
from /usr/bin/irb:9:in `<main>'



# gem list
<internal:lib/rubygems/custom_require>:29: [BUG] Segmentation fault
ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-linux]

-- control frame ----------
c:0005 p:---- s:0018 b:0018 l:000017 d:000017 CFUNC :require
c:0004 p:0013 s:0014 b:0014 l:000013 d:000013 METHOD
<internal:lib/rubygems/custom_require>:29
c:0003 p:0011 s:0009 b:0009 l:0012e8 d:0001f0 EVAL /usr/bin/gem:8
c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH
c:0001 p:0000 s:0002 b:0002 l:0012e8 d:0012e8 TOP
---------------------------
-- Ruby level backtrace information
----------------------------------------
/usr/bin/gem:8:in `<main>'
<internal:lib/rubygems/custom_require>:29:in `require'
<internal:lib/rubygems/custom_require>:29:in `require'

-- C level backtrace information
-------------------------------------------
/usr/bin/ruby(rb_vm_bugreport+0xa1) [0x529241]
/usr/bin/ruby [0x56ce16]
/usr/bin/ruby(rb_bug+0xb1) [0x56cf91]
/usr/bin/ruby [0x4b6f8f]
/lib64/libpthread.so.0 [0x34b680ed30]
/lib64/libc.so.6(memcpy+0x286) [0x34b5883a56]
/usr/bin/ruby(rb_iseq_compile_node+0xc1) [0x5089d1]
/usr/bin/ruby(rb_iseq_new_with_opt+0xa6) [0x510336]
/usr/bin/ruby [0x4ff1a1]
/usr/bin/ruby [0x501d0a]
/usr/bin/ruby [0x500cba]
/usr/bin/ruby(rb_iseq_compile_node+0x991) [0x5092a1]
/usr/bin/ruby(rb_iseq_new_with_opt+0xa6) [0x510336]
/usr/bin/ruby [0x4ff1a1]
/usr/bin/ruby [0x5021f7]
/usr/bin/ruby [0x500cba]
/usr/bin/ruby(rb_iseq_compile_node+0x780) [0x509090]
/usr/bin/ruby [0x50fd5a]
/usr/bin/ruby(rb_iseq_new_top+0x2c) [0x50fffc]
/usr/bin/ruby [0x570f54]
/usr/bin/ruby(rb_require_safe+0x44f) [0x57228f]
/usr/bin/ruby [0x5270ff]
/usr/bin/ruby [0x519439]
/usr/bin/ruby [0x51e698]
/usr/bin/ruby(rb_iseq_eval_main+0x290) [0x51ea20]
/usr/bin/ruby [0x417cf3]
/usr/bin/ruby(ruby_run_node+0x36) [0x4199e6]
/usr/bin/ruby(main+0x4d) [0x416f2d]
/lib64/libc.so.6(__libc_start_main+0xfa) [0x34b581e32a]
/usr/bin/ruby [0x416e19]

[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

Aborted


What does one do to even troubleshoot this let alone fix it?
 
R

Ryan Davis

I have recently upgraded from Ruby 1.8.7 to 1.9.2p180 on Fedora. After a
period of time, a day perhaps, the installation goes corrupt. It works
perfectly fine initially then everything fails. I am rolling this from
source with typical ./configure/make/make install type process. A few
examples:
Click to expand...

What C extensions might you have loaded?
 
C

Chip Burke

Ryan Davis wrote in post #988782:
What C extensions might you have loaded?
Click to expand...

Forgive my ignorance as I am a syadmin and don't delve into those parts.
How can I find this information out? I am certain this is not a hardware
issue as this same problem has arisen on every box I have ever tried
this on.
 
B

brabuhr

Ryan Davis wrote in post #988782:

Forgive my ignorance as I am a syadmin and don't delve into those parts.
How can I find this information out? I am certain this is not a hardware
issue as this same problem has arisen on every box I have ever tried
this on.
Click to expand...

Can you provide more details of your process?

* Install Fedora x on y (e.g. 13 on x86_64)
* Install Ruby 1.8.7-? via yum or source
* if source, what configure flags/prefix/etc
* Download and extract 1.9.2-?
* ./configure
* any flags here? are you overwriting 1.8.7 in-place or
installing into a prefix
* ...
* ...
 
C

Chip Burke

unknown wrote in post #989053:
Can you provide more details of your process?

* Install Fedora x on y (e.g. 13 on x86_64)
* Install Ruby 1.8.7-? via yum or source
* if source, what configure flags/prefix/etc
* Download and extract 1.9.2-?
* ./configure
* any flags here? are you overwriting 1.8.7 in-place or
installing into a prefix
* ...
* ...
Click to expand...


Install Fedora/CentOS. It has been a mixed bag thus far. Mostly x86_64
systems. CentOS 5.3-5.5 or Fedora 8-13.

Ruby 1.8.7 is installed via source.
/configure --prefix=/usr
make
make install

Gems then installed via #ruby setup.rb. I have always just grabbed the
latest/greatest gem version. 1.3.9, 1.6.2, etc

Use gems to install passenger, rails, etc.

6 months later developer says "I gotta have 1.9.2!"

Ok, now for 1.9.2 I follow the same procedures.
/configure --prefix=/usr
make
make install

And being that gems is included in 1.9x, I skip the gem install. Then
use gem to install rails etc.

Everything works just peachy... gems install, apps run... then
mysteriously a day or so later everything curls up and dies like noted
above.
 
M

Matt Lawrence

Ok, now for 1.9.2 I follow the same procedures.
./configure --prefix=/usr
make
make install

And being that gems is included in 1.9x, I skip the gem install. Then
use gem to install rails etc.

Everything works just peachy... gems install, apps run... then
mysteriously a day or so later everything curls up and dies like noted
above.
Click to expand...

You should check to see if you have the auto updates using yum configured.

-- Matt
It's not what I know that counts.
It's what I can remember in time to use.
 
C

Chip Burke

Matt Lawrence wrote in post #989062:
You should check to see if you have the auto updates using yum
configured.

-- Matt
It's not what I know that counts.
It's what I can remember in time to use.
Click to expand...

Yum is absolutely off. I can't imagine if it were on. Everything would
be blowing out everywhere as PHP, Python, Perl, etc are all compiled
form source and yum would butcher all of them.
 
B

brabuhr

6 months later developer says "I gotta have 1.9.2!"
Click to expand...

Have you looked into something like RVM to help manage multiple
versions of Ruby installed in independent prefixes?
Ok, now for 1.9.2 I follow the same procedures.
./configure --prefix=/usr
make
make install

And being that gems is included in 1.9x, I skip the gem install. Then
use gem to install rails etc.

Everything works just peachy... gems install, apps run... then
mysteriously a day or so later everything curls up and dies like noted
above.
Click to expand...

Thanks. Do you have any hosts running 1.9 that was not installed over
a 1.8 install? (I assume your hosts that only ever had 1.8 installed
never behaved like this.)
 
C

Chip Burke

unknown wrote in post #989064:
Have you looked into something like RVM to help manage multiple
versions of Ruby installed in independent prefixes?

Thanks. Do you have any hosts running 1.9 that was not installed over
a 1.8 install? (I assume your hosts that only ever had 1.8 installed
never behaved like this.)
Click to expand...

Correct. 1.8.x installs have been stable for a long while starting with
1.8.5 several years back. And these are all indeed upgrades from 1.8.x.

RVM has been discussed but the thought was get 1.9.x working first as a
proof of concept, but I suppose RVM could work the opposite way and
insulate versions. Regardless, one would think you could get a global
install of 1.9.2 working as Fedora and CentOS aren't exactly back water
odd ball distros.
 
B

brabuhr

Correct. 1.8.x installs have been stable for a long while starting with
1.8.5 several years back. And these are all indeed upgrades from 1.8.x.

RVM has been discussed but the thought was get 1.9.x working first as a
proof of concept, but I suppose RVM could work the opposite way and
insulate versions. Regardless, one would think you could get a global
install of 1.9.2 working as Fedora and CentOS aren't exactly back water
odd ball distros.
Click to expand...

I have run 1.9.x on CentOS (PREFIX=3D/usr/local) with no issues, but I
don't know why you *later* have trouble installing it over 1.8.7 in
/usr.
 
R

Ryan Davis

unknown wrote in post #989053:
Click to expand...

kk. no problem. Basically, are there any .so files in any of the lib =
dirs of the gems you've installed?

What's this say?

% gem env path

then:

% ls $(gem env path)/gems/*/lib/**/*.so

In my case:

% ls $(gem env path)/gems/*/lib/**/*.bundle
/Library/Ruby/Gems/1.8/gems/nokogiri-1.4.4/lib/nokogiri/nokogiri.bundle
=
/Library/Ruby/Gems/1.8/gems/sqlite3-1.3.3/lib/sqlite3/sqlite3_native.bundl=
e
Install Fedora/CentOS. It has been a mixed bag thus far. Mostly x86_64=20=
Click to expand...
systems. CentOS 5.3-5.5 or Fedora 8-13.
=20
Ruby 1.8.7 is installed via source.
./configure --prefix=3D/usr
make
make install
=20
Gems then installed via #ruby setup.rb. I have always just grabbed the=20=
Click to expand...
latest/greatest gem version. 1.3.9, 1.6.2, etc
=20
Use gems to install passenger, rails, etc.
=20
6 months later developer says "I gotta have 1.9.2!"
=20
Ok, now for 1.9.2 I follow the same procedures.
./configure --prefix=3D/usr
make
make install
=20
And being that gems is included in 1.9x, I skip the gem install. Then=20=
Click to expand...
use gem to install rails etc.
=20
Everything works just peachy... gems install, apps run... then=20
mysteriously a day or so later everything curls up and dies like noted=20=
Click to expand...
above.
Click to expand...

% env | egrep "GEM|RUBY"

In my case:

10006 % env | egrep "GEM|RUBY"
GEM_PATH=3D/Library/Ruby/Gems/1.8

which can cause hell on wheels when I run ruby 1.9=
 
C

Chip Burke

Some more news. I built a clean Fedora 13 x86_64 box last night to test
1.9.2 in a non-upgrade environment. Exact same results. By morning ruby
was spaghetti.

Ok, to answer Ryan's questions (Thank you very much for taking the time
on this by the way). Of course those commands fail when in the corrupt
state.

'gem env path' says
/root/.gem/ruby/1.9.1:/usr/lib/ruby/gems/1.9.1

Instead of ls I used find.

#find /usr/lib/ruby/gems/1.9.1 -name *.so

Returned nothing and the other path in root doesn't exist.

#env | egrep "GEM|RUBY"

Also nothing
 
A

Adrian Perez

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have recently upgraded from Ruby 1.8.7 to 1.9.2p180 on Fedora. After a
period of time, a day perhaps, the installation goes corrupt. It works
perfectly fine initially then everything fails. I am rolling this from
source with typical ./configure/make/make install type process. A few
examples:

#irb
<internal:lib/rubygems/custom_require>:29:in `require': closed stream
(IOError)
from <internal:lib/rubygems/custom_require>:29:in `require'
from /usr/lib/ruby/1.9.1/irb.rb:13:in `<top (required)>'
from <internal:lib/rubygems/custom_require>:29:in `require'
from <internal:lib/rubygems/custom_require>:29:in `require'
from /usr/bin/irb:9:in `<main>'



# gem list
<internal:lib/rubygems/custom_require>:29: [BUG] Segmentation fault
ruby 1.9.2p180 (2011-02-18 revision 30909) [x86_64-linux]

-- control frame ----------
c:0005 p:---- s:0018 b:0018 l:000017 d:000017 CFUNC :require
c:0004 p:0013 s:0014 b:0014 l:000013 d:000013 METHOD
<internal:lib/rubygems/custom_require>:29
c:0003 p:0011 s:0009 b:0009 l:0012e8 d:0001f0 EVAL /usr/bin/gem:8
c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH
c:0001 p:0000 s:0002 b:0002 l:0012e8 d:0012e8 TOP
---------------------------
-- Ruby level backtrace information
----------------------------------------
/usr/bin/gem:8:in `<main>'
<internal:lib/rubygems/custom_require>:29:in `require'
<internal:lib/rubygems/custom_require>:29:in `require'

-- C level backtrace information
-------------------------------------------
/usr/bin/ruby(rb_vm_bugreport+0xa1) [0x529241]
/usr/bin/ruby [0x56ce16]
/usr/bin/ruby(rb_bug+0xb1) [0x56cf91]
/usr/bin/ruby [0x4b6f8f]
/lib64/libpthread.so.0 [0x34b680ed30]
/lib64/libc.so.6(memcpy+0x286) [0x34b5883a56]
/usr/bin/ruby(rb_iseq_compile_node+0xc1) [0x5089d1]
/usr/bin/ruby(rb_iseq_new_with_opt+0xa6) [0x510336]
/usr/bin/ruby [0x4ff1a1]
/usr/bin/ruby [0x501d0a]
/usr/bin/ruby [0x500cba]
/usr/bin/ruby(rb_iseq_compile_node+0x991) [0x5092a1]
/usr/bin/ruby(rb_iseq_new_with_opt+0xa6) [0x510336]
/usr/bin/ruby [0x4ff1a1]
/usr/bin/ruby [0x5021f7]
/usr/bin/ruby [0x500cba]
/usr/bin/ruby(rb_iseq_compile_node+0x780) [0x509090]
/usr/bin/ruby [0x50fd5a]
/usr/bin/ruby(rb_iseq_new_top+0x2c) [0x50fffc]
/usr/bin/ruby [0x570f54]
/usr/bin/ruby(rb_require_safe+0x44f) [0x57228f]
/usr/bin/ruby [0x5270ff]
/usr/bin/ruby [0x519439]
/usr/bin/ruby [0x51e698]
/usr/bin/ruby(rb_iseq_eval_main+0x290) [0x51ea20]
/usr/bin/ruby [0x417cf3]
/usr/bin/ruby(ruby_run_node+0x36) [0x4199e6]
/usr/bin/ruby(main+0x4d) [0x416f2d]
/lib64/libc.so.6(__libc_start_main+0xfa) [0x34b581e32a]
/usr/bin/ruby [0x416e19]

[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

Aborted


What does one do to even troubleshoot this let alone fix it?
Click to expand...
All right,
That's weird. I agree. I don't have a lot of experience using
distribution-provided rubies. So I'll try to take my point the clearest
I can. First than anything that kind of output doesn't really help a
lot, all I can see here is that it came to crash on some kind of memory
issue which you can't determine by the backtrace at all. Attaching gdb
to the process and watching that thing crash or getting a core dump will
bring more light to that.
On the other hand, do you appear to have left-overs from an older
install? Are you sure you're not somehow getting to load a shared
library (.so file) belonging to an old installation?
If you haven't solved or went through a workaround by the time you read
this, then let me know I'd be trying to help you through it.

- --
Best Regards,

Adrian Perez
http://www.adrianperez.org

Twitter: @blackxored | Skype: blackxored | Google Voice: (559) 744 3201
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iQIcBAEBAgAGBQJNjLBKAAoJEF9FgjLdFu0kJZ8P/1c5KOe3Vlm0E6vl86ZjEyl+
plfKuP4WHGw/DEIdQjMfaVaqosMqDudPRph5oi1h4rVgN8CaVDimq7q0oAn9h23L
xoT+h3zlBFV/Hr9UKE41/W3zWnf3jWhy5YospIRCDnkopvlibiHo0RLWl0SWgc0S
N4gwSzVAX5NEmnbAff9dhXReeKv8XOGtQzUYK8yv2PQpZz/vgUJAWoUUSkmTKgmR
H8M/cEJhHsS3Hj+1zesT0XWqkjU4U2Y+dSJoN/GCulERX1sBHR7to2lfu/Cz5G28
WSK/Sj2Xp9nyg/iZ8AvcoV9XJHxxRu8J61Y89CgJEFHmpTZzrttrYQCs0sU+eQYV
6TkpoQ2bm3wwTGQGJIpwY3PgBFW0cBWCOq0dbEKwYYWB4qca9Arb1zFlYpYRlAVT
n4h9IoRZmHC24SuU1Ej4LB0UkGCuwhJx/Re289QGWA1ILicE7fzRHv9A9/7rKpEK
LVzo/axzhDr047u1RmfhjbG4f6M7YedWOwtMO6TcdBONLhxvd9orvDtuLtwH8Rcp
DkPXDQQl/yPGg7K8Vewj5p+JULc4Jr3hQZGaTsfknrHrrrq+Ly0MM0ZGeisoGzN2
JD2bSTNi5zNPYJraedUEkExCUSfKvPerwIcv1NNKZcOGRPrNASpph9voElYnJAz8
dghNcfl8PGe9Nhf8qMnJ
=OLxU
-----END PGP SIGNATURE-----
 
B

brabuhr

Some more news. I built a clean Fedora 13 x86_64 box last night to test
1.9.2 in a non-upgrade environment. Exact same results. By morning ruby
was spaghetti.
Click to expand...

Thanks for testing that. Did you also test installing to a different PREFIX?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

Installing Ruby on Solaris 10 1
Anyone successfully using Ruby to access a Sybase database(either DBIor SQLAnywhere gem) 2
`require': no such file to load -- rubygems (LoadError) 2
`dir_config': undefined method `split' 1
wx on Ubuntu 10.10 doesn't work 1
RubyInline and Digest::Base error 0
parsedate (LoadError) 1.9.2 1
windows net/ping load error 0

Members online

No members online now.
Total: 47 (members: 0, guests: 47)
Robots: 434

Forum statistics

Threads
473,769
Messages
2,569,576
Members
45,054
Latest member
LucyCarper

Latest Threads

Top