This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Use malloca instead alloca


On Sun, Dec 30, 2012 at 1:45 PM, Rich Felker <dalias@aerifal.cx> wrote:
> On Sun, Dec 30, 2012 at 12:48:50PM -0500, KOSAKI Motohiro wrote:
>> >> For platform specific way best solution is to read where bottom of stack is
>> >> and allocate only when at least say 32768 bytes are left.
>> >> >
>> > And when knowing stack boundaries I could also recognize stack pointer
>> > by single comparison.
>> >
>> > It needs to define _STACK_TOP,_STACK_CUP, _STACK_SIZE macros for stack parameters.
>> > I can find them by pthread_attr_getstack but this call is slow.
>>
>> I think this approach has two issues.
>>
>> 1) On LInux, RLIMIT_STACK doesn't affect to main thread. so there is
>> no reliable stack limit detection way. Think mmap vs stack expansion
>> race case for example.
>
> I'm not sure this is correct, or perhaps I don't understand. The
> entire virtual memory range covered by RLIMIT_STACK is reserved for
> stack growth, but only the first 128k (this number seems to be
> hard-coded in the kernel..?) is initially reserved in the
> commit-charge sense.

Damn. I wrote incorrect. I'm very sorry. I'd like to try clarify. On
linux main thread,
it doesn't reserve RLIMIT_STACK size virtual memory. but automatically expand
a stack when needed and then makes SEGV if exceed RLIMIT_STACK.

Then, the trouble is happen when virtual memory is very tight. mmap()
may allocate
a virtual memory very near place of ESP and it prevent to expand to
stack. So, stack
access can make SEGV even if stack size < RLIMIT_STACK.

Thank you.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]