No, I didn't say it couldn't find the interpreter, I said that it found the WRONG one (or a different one, anyway) that works differently than the one he's using to test on.
Also, on Solaris you probably have word alignment issues you didn't have on the other machine. Solaris (at least on sparc) has some pretty critical requirements on pointers pointing to the right alignment.
(IIRC, x86-style processors will handle that, just slower than a 'correctly-aligned' access).
E.G. if your memory address is 0x1001 as a byte address, but your computer requires word (say 16-bit words) alignement, trying to get a word from that address WILL cause a segv (AFAICR). that is:
int * foo = 0x1001;
printf("My foo (0x%x), on a byte alignement, will segv here on a word-align machine %d\n",foo,*foo);
-----Original Message-----
From: plug-discuss-bounces@lists.phxlinux.org on behalf of Matt Graham
Sent: Sat 6/22/2013 12:26 PM
To: Main PLUG discussion list
Subject: RE: Linux segmentation fault message
>> 'qsearch' works fine on my local computers, but when I try to run it
>> on my web host I see this error message:
>> ~(location) line 6: 26955 Done
>> fgrep -y "$name1" q-hid
>> 26956 Segmentation fault | fgrep -y "$name2" > tempz
From: "Carruth, Rusty"
> you left off the first line:
> #!/bin/bash
True, but it should've died immediately if it couldn't find the interpreter,
not a few lines down.
Is this a shared server, or a VPS? I ask mostly because a long long time ago,
I had a little C program that malloc()ed an array, filled it with random
numbers, and ran a set of tests on it. This program always segfaulted after a
few iterations when run on the shared Solaris machines. On my home box, it
always ran to completion. Same C, same gcc invocation. The only thing that
made any sense was that the little program was consuming too much RAM or CPU
and getting sent a SIGSEGV by whatever "prevent runaway user processes from
eating everything" system they had set up. Using nice on it didn't seem to
help, and I was malloc()ing a few hundred K at most.