This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Use malloca instead alloca
On Sun, Dec 30, 2012 at 01:45:55PM -0500, Rich Felker 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.
On Sun, Dec 30, 2012 at 02:18:11PM -0500, KOSAKI Motohiro wrote:
> 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.
As value allocated on stack is value not allocated on heap this would
delay this condition. If 4mb were allocated on stack then with
fragmentation ratio 2 you could allocate additional 2mb until this
happen.
>
> > 2) setcontext/getcontext family provide to implement userland thread
> > (it is sometimes called fiber or green thread). so
> > pthread_attr_getstack is not suitable for getting generic stack
> > knowledge.
I was writing platform specific which could include adding counters in
nptl/allocatestack.c, pthread_attr_getstack was meant as starting point.
Anyway I realized that this is not needed for detection, it suffices to
compare with %esp and %ebp or analogs on other architectures.
>
> Also, signal handlers can be run on alternate stacks with sigaltstack,
> and it's possible to call non-async-signal-safe functions in libc from
> such signal handlers as long as you can ensure they did not interrupt
> unsafe functions. A trivial way to do this is raise().
>
> I agree it's wrong to try to measure the available stack space. Even
> if it could be done reliably, you don't want to consume most of the
> remaining stack space with alloca when the function is not a leaf
> function, and other functions it calls still might need significant
> stack space. It's really just bad policy for any function to use more
> than a small, bounded amount of stack space.
This is not big problem. We could change bound from size-32768 to size/2.
Or additionaly keep counter of memory used my malloca and
allocate until size/2 is hit.
Anyway original question was how handle malloca in loop, and some counter
is necessary.
>
> Rich