On Thu, Jun 19, 2003, Orna Agmon wrote about "Re: [Haifux] stack size":
> Eli, I am not trying to prove a point, but find something automatic that
> will tell me when the struct is too large, and I should use the heap. I
Ok, here's an automatic algorithm for you: for each structure you have
defined in your program and initialized as an automatic variable, add code:
if(sizeof(thestruct) > 1000){
fprintf(stderr,"thestruct is a very big struct!\n");
}
(exercise: do this automatically using a Perl script, or whatever).
Note that the size of the structure is a compile-time constant (unless
you're using either alloca() or the C99 variable-sized arrays, but you
probably aren't). So I completely fail to see what your problem is...
It's not a run-time problem that something like valgrind needs to find -
it's a design issue in your program that you simply should not have huge
(i.e., megabytes in size) structures on the stack.
It's also not a major portability issue - on *any* system you should
put only small things on the stack, not huge arrays and things like that.
I know of no system that handles stack allocation gracefully - this is
because the stack is good for what it was intended for (recursive function
calls) and not for what it wasn't intended for (generic allocation of
large objects).
> only relized that that struct was too big, when I had a segmentation
> fault. I want to be able to tell beore this happens, using an automatic
> tool. (As I said, I thought valgrind would do that for me- since I am now
> converting code from fortran to C, I realize every now and then that
> another struct is too large for the stack)
Another idea is to set the stack limit (with ulimit) to something very
small; You're bound to find these problems more quickly.
> Is there anything that protects the stack efficiently?
Orna, as I explained earlier, you can't further "protect" the stack. In
fact the SIGSEGV you're getting *is* protection - your program gets killed
as it tries to overflow the stack. There's simply nothing else that can be
done at this point - your program insists on allocating an automatic variable
on the stack, and there is no room. Trying to grow or move the stack at
this point is possible but completely unportable, and frankly, not a very
wise idea. It is especially difficult to move or grow stacks in multi-threaded
programs, which need to hold many stack areas (so the typical paradigm of
'heap grows up, stack grows down' no longer helps).
> Is there any variable which holds the stack size, such that I can compare
> sizeof(a_t) to that?
No portable way that I know of. But again, why do you care? any
sizeof(a_t)>1000 (for example) is most likely a mistake and you should
(or at least) fix it.
--
Nadav Har'El | Thursday, Jun 19 2003, 19 Sivan 5763
[EMAIL PROTECTED] |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |You have the right to remain silent.
http://nadav.harel.org.il |Anything you say will be used against you.
--------------------------------------------------------------------------
Haifa Linux Club Mailing List (http://www.haifux.org)
To unsub send an empty message to [EMAIL PROTECTED]
