I'm trying to have my Rails website running on my fresh installation of
Mountain Lion Server. Not using RVM, because I don't need many rails or
ruby installations. Configuring ruby and rails to run smoothly is a pain
in the ass.
Compiled the newest version of OpenSSL with these commands:
sudo ./configure --prefix=/usr/local/ darwin64-x86_64-cc
sudo make
sudo make install
Now when I type I get this:
grid:ruby-1.9.3-p392 Clu$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
When I try to configure Ruby from source, I get to Segmentation Fault:
I'm trying to have my Rails website running on my fresh installation of
Mountain Lion Server. Not using RVM, because I don't need many rails or
ruby installations. Configuring ruby and rails to run smoothly is a pain
in the ass.
Compiled the newest version of OpenSSL with these commands:
sudo ./configure --prefix=/usr/local/ darwin64-x86_64-cc
sudo make
sudo make install
Now when I type I get this:
grid:ruby-1.9.3-p392 Clu$ openssl version
OpenSSL 1.0.1e 11 Feb 2013
When I try to configure Ruby from source, I get to Segmentation Fault:
Signal 11 is SIGSEGV (segmentation fault). That has nothing to do
with hardware - unless you want to suggest that the MMU is involved in
the process. This typically happens when dereferencing null pointers.
Piotr, I'd start with simpler options - typically you do not need the
sudo's for configuring and compiling. Also I'd omit the architecture
unless you are cross compiling.
./configure --prefix=/usr/local/
make
sudo make install
Kind regards
robert
···
On Sat, Mar 9, 2013 at 6:35 PM, Miroslaw Niegowski <trednu@gmail.com> wrote:
signal 11 suggests a hardware error and is not related to software. I would
check ram first.
SIG11 is not _usually_ a hardware error, though it can be related to memory issues. A SIG11 can be thrown when something tries to read or write to a memory area it doesn't have permissions on OR when it does and the area is corrupt. (Usually caused when memory cells have gone bad on individual sticks). Also happens when the addresses on the stack have become corrupt, again usually due to bad cells on the/a memory stick. The main issue though is that the pointer to a memory location is invalid.
Run up against this so many times over the last 15+ years of computing, its not funny. In *some* cases, swapping out memory sticks has solved the issue.
*That being said*, the most common issue that raises SIG11s are bugs in programs. (Bad pointer math, etc) There is no real way, short of testing your individual memory sticks in a hardware based memory tester (not something like mem86+ or Microscope), to determine if its specifically your memory or a bug in the software. There are subsystems that can throw this, hardware based, like overclocking memory and/or CPUs.
However, the vast majority of SIG11s thrown are due to bugs in programs, not hardware. Just don't totally discount hardware, is the point.
···
Robert Klemme <mailto:shortcutter@googlemail.com>
March 11, 2013 3:58 PM
Signal 11 is SIGSEGV (segmentation fault). That has nothing to do
with hardware - unless you want to suggest that the MMU is involved in
the process. This typically happens when dereferencing null pointers.
Piotr, I'd start with simpler options - typically you do not need the
sudo's for configuring and compiling. Also I'd omit the architecture
unless you are cross compiling.
./configure --prefix=/usr/local/
make
sudo make install
Kind regards
robert
Miroslaw Niegowski <mailto:trednu@gmail.com>
March 9, 2013 12:35 PM
Hi,
signal 11 suggests a hardware error and is not related to software. I would check ram first.
--
D. Deryl Downey
"The bug which you would fright me with I seek" - William Shakespeare - The Winter's Tale, Act III, Scene II - A court of Justice.
