Bug#343853: Bug in glibc: setrlimit
Please use group reply, so that you do not drop the bug tracking system
from CC.
On Mon, Dec 19, 2005 at 10:28:23AM -0500, Gene Cooperman wrote:
> I'd like to repeat this in my own words, to see if I understand your point.
> You seem to be saying that:
> A. The parent process begins with the user's default stack size
> B. The parent calls setrlimit to change the limit on the stack size.
> However, this does not change the actual stack size of the process.
> It only affects how big it can grow.
> C. The parent calls pthread_create(), which receives a copy of the
> current stack size.
> D. The child is created, and its stack size is set to the soft limit
> of the parent's stack size, and not to the parent's current stack size.
> E. When the child calls pthread_create(), it tries to create a second
> stack of that size, and fails.
'The user's default stack size' doesn't mean anything.
There are two stack sizes: those used by the kernel when creating a new
process, and those used by the thread manager when creating a new
thread. The thread manager initializes its default stack size, based
on the rlimits, when the process is first created. This is used for
pthread_create if the application doesn't specify its own stack size.
> If the above is correct, then here is what doesn't make sense to me:
> 1. If we execute with the debugging version of glibc:
> LD_LIBRARY_PATH=/usr/lib/debug ./a.out
> then step D above is different: the child is apparently created
> with some stack size that is strictly smaller than the soft limit
> of the parent's stack size.
One of these glibcs is NPTL, the other (in /usr/lib/debug)
LinuxThreads. They behave slightly differently. They implement
roughly the same thing, but the details do vary. I vaguely recall that
one of them caps at an arbitrary limit and the other does not.
> 2. If the parent's hard limit is not RLIM_INFINITY, but something slightly
> smaller, then step D above is different: the child is apprently created
> with some stack size that is strictly smaller than either the
> soft limit or the hard limit of the parent's stack size.
>
> Why should the child have its stack initialized the soft limit of the
> parent _only_ if the parent has a hard limit less than RLIM_INFINITY,
> and _only_ if we don't use the libc.so library with debugging symbols retained?
>
> If steps A through E are a feature, then shouldn't the feature continue
> to work _even_ if we are using a debugger and debugging libraries?
> Also what is the motivation for enabling this feature only when
> the hard limit is RLIM_INFINITY? I understand that RLIM_INFINITY
> implies that the O/S may turn off error checking, but why does that
> imply that the O/S should turn on this feature?
Glibc doesn't care about the hard limit. It never checks it. Your
observations must be reflecting something different.
I suggest you take a glibc source tree and look for the places where
NPTL and LinuxThreads consult the stack rlimit, if you need to
understand what is happening any more precisely than I've explained it.
--
Daniel Jacobowitz
CodeSourcery, LLC
Reply to: