Re: _Very_ strange problem with compiling

["Gary Hennigan" <glhenni@sandia.gov>]

"Mark Phillips" <mark@infoeng.flinders.edu.au> writes:
> Thanks for this!  I increased the stack size via "ulimit -s <size>"
> and the thick4 executable no longer crashes.
> 
> However the curious thing is that with test.c, I thought "surely by
> increasing N I could make it seg fault too" but I can't, even
> 
> #define N 200000000
> 
> runs fine.  (c.f. #define N 209677 for thick4.c) (Remember that test.c
> and thick4.c are identical apart from name --- and now size of N.)
> 
> Perhaps my understanding of what the stack is and how it works is
> wrong.  (Basically it is where local variables are stored --- or is
> there more to it than that?)
> 
> Perhaps the compiler does things differently depending on how big
> the name space is?
> 
> Anyway, thanks again for your help.

I did something really dumb once. I had a code called test.c and I
compiled it to a binary called test. Nothing particularly wrong with
that, but when I ran it I didn't use an explicit path like:

% ./test

but rather

% test

My path also looked something like:

PATH=/usr/bin:/bin:.

Note that my current working directory is at the end of my path. Well,
duh, "test" is, on many unix systems, and in many shells, a standard
utility or builtin, respectively. So it turned out I was using, for
example, /usr/bin/test when I didn't specify the explicit path to my
compiled "test" executable.

Not saying you're as dumb as I was, but are you sure you're running
your compiled "test" executable and not the standard utility, on
Debian, /usr/bin/test? Make sure you specify the path to your "test"
executable explicity, or better yet, rename the executable to
something like "mytest", ie., 
        
% cc test.c -o mytest
% ./mytest

Gary

P.S. To be fair to myself this was 8 or so odd years ago and I was a
newbie! :)