Linux segmentation fault message

Matt Graham danceswithcrows at usa.net
Sat Jun 22 14:03:46 MST 2013


From: "Carruth, Rusty"
> No, I didn't say it couldn't find the interpreter, I said that it
> found the WRONG one (or a different one, anyway)

On a Linux box, if you have a file called "foo.sh" which has +x perms, and you
don't have a #! line, either bash or sh is chosen as the interpreter.[0]  If I
cut-n-paste the original script joe put together into a file called temp.sh ,
and I try to execute it, I get an infinite loop of

Press S to search >>> ./temp.sh: line 2: readin: command not found

./temp.sh: line 10: cls: command not found
Not a valid option.

...so it's highly probable that Joe forgot to put it in, and he's running this
script on something that's not a Linux box, or has "#!/usr/bin/tcsh" or
"#!/usr/bin/zsh" as the first line.

> Also, on Solaris you probably have word alignment issues.  Solaris
> (at least on sparc) has some pretty critical requirements on
> pointers pointing to the right alignment.
 
The code was ~- 50 lines and dealt with doing basic math on a bunch of ints
and printf()ing results.  I don't think pointer alignment was the problem,
because I could do "testarray 10" and it'd run for 1 or 2 seconds before
segfaulting, displaying results for 10..14, then "testarray 14", and it'd run
for 1 or 2 seconds before segfaulting, displaying results for 14..18, and so
forth.  This pattern kept up, though sometimes it'd go for 5 or 6 number sets
before segfaulting.  This happened whether I used cc or gcc for the code in
question, making pointer alignment problems less likely.

I really think it was due to them having "1 user process can use at most 2-3
CPU seconds before being killed" rules in place.  I had a much larger and more
complex program that ~30 other people used, which never segfaulted for
anything that was traceable back to pointer alignment.  "Matt wrote bad code"
or "user did something that was really stupid which Matt didn't anticipate"
were the main cause of problems there....

[0] strace ./temp.sh exits immediately with -1 ENOEXEC (exec format error),
but ./temp.sh actually tries to execute the code.  This is a bit odd.  "bash
./temp.sh" and "sh ./temp.sh" behave exactly as ./temp.sh does.  I'm guessing
the script is actually in tcsh, but ICBW.

-- 
Matt G / Dances With Crows
The Crow202 Blog:  http://crow202.org/wordpress/
There is no Darkness in Eternity/But only Light too dim for us to see



More information about the PLUG-discuss mailing list