Re[2]: maximum number of variables?

[Miguel A. Nuñez <miguel dot nunez at terra dot es>]

>> 
>> 
>> ILT> Bob Rossi <bob@brasko.net> writes:
>> 
>> >> On Tue, Aug 30, 2005 at 10:54:02PM +0100, Lexington Luthor wrote:
>> >> 
>> >> > I think for large arrays, its best to allocate them from the heap. Use
>> >> > malloc() or new (if using C++).
>> >> 
>> >> I've always been told that the heap and stack grow towards each other.
>> >> If this is true, why would it be OK to create the item on the heap, vs
>> >> on the stack? If it's not true, could someone simply explain how this
>> >> works?
>> 
>> ILT> You are correct in theory.  In practice the heap and stack have
>> ILT> different limits, and the limit on the heap is much larger than the
>> ILT> stack (if running bash, compare ulimit -s and ulimit -v).  And if you
>> ILT> worry about portability, on some platforms allocating a large stack
>> ILT> frame will simply fail, and on some other platforms it will require
>> ILT> extra work to emit stack probes to tell the OS that you are
>> ILT> intentionally extending the stack rather than just referencing a
>> ILT> random memory address.
>> 
>> ILT> Ian
>> 
>> 
>> Ian,
>> 
>>   I did ulimit -s and ulimit -v in a solaris 9 sun machine.
>> ulimit -s returns 8192, ok, but ulimit -s returns unlimited. Does
>> this make sense?

BR> Assumming you mean ulimit -s = 8192 and ulimit -v  = unlimited, then
BR> yes, I suppose that makes sense. On my linux machine, ulimit -s and
BR> ulimit -v = unlimited. In this case, I suppose it's possible that if the
BR> array was on the stack and things borked, it would also bork when on the
BR> heap. However, in your case, I know understand why things would work for
BR> you if you moved from the stack to the heap.

BR> Bob Rossi


Yes, I meant that Bob. Anyway, remember it was Nicolas who originally had this problem. I'm running into a similar problem, so I tried the commands Ian suggested, and the value 'unlimited' was strange to me.

Let's see if anyone can help me with my problem. My application creates a new thread for a receiving infite loop. pthread_create runs the function containing the loop, and this functions defines a local variable that is a huge struct (sizeof returns 984KB). I initialize it using 'mystruct_t mystruct={0}'.

Up to this point everything is ok. When something is received, the loop calls a new function. This function creates a new local variable, the same struct. Here the program crashes.

I have read the default stack size when creating a thread in solaris 32 bits is 1MB, so I thought the crash would be due to allocating more memory than the stack size.

I put the initialization in a separate line, with a for loop giving value 0 byte per byte, from 0 to sizeof(mystruct_t)-1. Strangely (at least to me) the second struct is allocated, and the crash is always produced when writing to the bytes of the struct.

Is it possible that the local variable is allocated partly into the stack and partly beyond the limits of the stack, so that when I write to it I get my segmentation fault?? How could I know where the stack begins and ends?

I will allocate the structs at the heap, instead of the stack, but I would like to understand this situation.