"Mark Phillips" <[EMAIL PROTECTED]> 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! :)
