This problem is not something that is specific to the version of ruby that you are using. It just comes with RVM, at least that is what I have observed since I started using RVM to manage different ruby version on my MacBook.
Now, the reason behind this problem is the SSL or OPENSSL that the ruby library is pointing to and the one that is installed on your system are not same. There are certain libraries that require using ssl, e.g if you try to send mail, or try do image processing in rails using any gem like carrierwave or paperclip etc, this problem may arise.
1. Install openssl package (if not already)
$ rvm pkg install openssl
2. Remove the already installed ruby version from RVM that is creating problem, in my case, it was 1.9.3-p125
$ rvm remove 1.9.3-p125
3. Re-install ruby version, 1.9.3-p125, specifying the openssl dir as well, so that ruby this time points to the correct openssl.
This should pretty muh resolve your problem of segmentation fault.
$ rvm install 1.9.3-p125 –with-openssl-dir=$rvm_path/usr
This is a problem which is actually not a problem if we are following right semantics of HTML.
Problem: I faced this problem where in after a page is loaded I have to add certain input html elements in the form (which I had inside a table) using ajax. Only the elements that were loaded when the page rendered were getting posted, but not the ones added using ajax after the page was loaded. This can be frustrating to figure out why the elements which were loaded by default are getting posted but the elements which rendered after wards using AJAX are not.
My Theory: When a DOM is loaded, the input elements, which are rendered inside TABLE cells get hooked to the FORM automatically because they are rendered when the DOM got loaded. And when the form is posted, its not the table, but the input elements which are hooked to the form get posted. Now, if you are rendering some elements through ajax, then those elements get hooked up only to the TABLE (in case the FORM is inside the TABLE) and not to the form.
Solution: Shift the TABLE inside the FORM. So, that when you add more elements dynamically, it gets hooked to the form as well.
TABLE — WORKS
FORM — NOT GOOD
This was a head breaking experience for me recently.
We all know that the fixtures files in rails load by default in alphabetical order. And the records inside every single file again load in alphabetical order (not from top to bottom as you define in the fixture file). Considering that having database level constraints (foreign keys, primary keys etc) is advisable idea in spite of having the rails model level relations (belongs_to, has_many etc), loading fixtures in alphabetical order is the most stupid thing I can ever think of. Imagine you have Account and Employee models and employee has_many accounts. So you have an employee_id sitting as a foreign key in the accounts table. Now you want to load your fixtures (rake db:fixtures:load), for test purpose say, which was my requirement. Since ‘A’ comes before ‘E’ in alphabetical order, rails tries to load the addresses first and then the employees fixture file. Obviously this fails because of foreign key violations. Database raising errors is perfectly making sense here. So I looked around for something which may solve this problem and found that there are solutions available given by some people. But what surprised me is that there is nothing that rails core provided for this.
Anyways, so for people who are into this kinda problem, here is the best one called ActiveFixture that I came across and wish that it would get included in the rails core someday.
Again there is something that may surprise you again. Its not that rails has been stupid all these days to leave us in such a situation. It might so happen that you may not do anything for ordering of the fixtures and still would not get any error although you have foreign key relationships in the database. The reason actually lies in the active record’s database (postgres, mysql sql-lite etc) adapters class. Here is how it goes. While loading the fixtures (I am giving postgres example, as I am using postgres for this project and found it there), rails calls the following method in ActiveRecord::ConnectionAdapters::PostgreSQLAdapter:
def supports_disable_referential_integrity?() #:nodoc:
version = query("SHOW server_version").split('.')
(version.to_i >= 8 && version.to_i >= 1) ? true : false
So this method says, that if you pgsql version is x.y.z, then if x >= 8 and y >= 1, then it will be able to defer the referential integrity for you and you could load the data from fixtures into your database easily without taking care of the ordering and without facing any data integrity errors Unfortunately I, in my team, was using 9.y.z version of pgsql and all my collegues were on 8.1.4. So they were not getting any errors and I was frustated to know WHY.
Well the secret lies in the ConnectionAdapters for rails I don’t know if we should take it as an advantage, that rails is trying to do or not, but until we have something more intelligent to infer the order of loading the fixtures files from the relationships in the models, rather than defining the load order manually as mentioned here, I am happy that its saving me some time.
Well after a long time, I finally had to shift back to ROR development on Windows. I am running on Windows Vista, Rails 3, ruby 1.9.2. Things are not all that bad on windows, or at least, not as much as I thought they might be. But, we definitely keep on facing problems here and there. There is one such which you also might face if you try development on Rails 3 with ruby 1.9.2. There seems to be a bug with the gems that are installed with the one click windows ruby installer. I am not sure why, but you may lead to see the following error message once you start using rake:
`bin_path’: can’t find executable rake for rake-0.8.7 (Gem::Exception)
Now the solution to get away from this bug as of this writing is that you will have to remove the rake.gemspec file from the “your_path_to\Ruby192\lib\ruby\gems\1.9.1\specifications” folder.
And you are good to go now. I do not have really too much time to dig into the matter as to why this might be happening, but it worked for me.
I was configuring the delayed job and I got problems like :
`method_missing_without_paginate’: undefined method `destroy_failed_jobs=’
This is because I have 2.0.3 version of delayed job… The configuration parameters have all been moved to Delayed::Worker now and thus the following works for version 2.x:
Delayed::Worker.destroy_failed_jobs = false
Delayed::Worker.sleep_delay = 60
Delayed::Worker.max_attempts = 3
Delayed::Worker.max_run_time = 5.minutes
or the following:
Delayed::Worker.destroy_failed_jobs = false
Delayed::Job.destroy_failed_jobs = false