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: compiling md5init.c compiling md5ossl.c linking shared-object digest/md5.bundle installing default md5 libraries compiling rmd160init.c compiling rmd160ossl.c linking shared-object digest/rmd160.bundle installing default rmd160 libraries compiling sha1init.c compiling sha1ossl.c linking shared-object digest/sha1.bundle collect2: ld terminated with signal 11 [Segmentation fault: 11] make: *** [../../../.ext/x86_64-darwin12.2.1/digest/sha1.bundle] Error 1 make: *** [ext/digest/sha1/all] Error 2 make: *** [build-ext] Error 2
on 2013-03-09 17:33
on 2013-03-09 18:36
Hi, signal 11 suggests a hardware error and is not related to software. I would check ram first. 09-03-2013 17:35, "Piotr P." <firstname.lastname@example.org> napisa(a):
on 2013-03-09 20:30
I don't think it's a hardware failure, checked and everything is all right.
on 2013-03-11 20:59
On Sat, Mar 9, 2013 at 6:35 PM, Miroslaw Niegowski <email@example.com> wrote: > signal 11 suggests a hardware error and is not related to software. I would > check ram first. 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 2013-03-11 21:31
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. > > > 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.