On Sat, 2010-07-17 at 02:22 -0300, Alberto Bertogli wrote: > Chasing a bug, I noticed that make sets RLIMIT_STACK to RLIM_INFINITY. > > In Linux (since 2.6.25), that actually triggers a very subtle behaviour > change in the way the kernel manages the memory layout. While most > applications are oblivious to it, some are not and can cause issues that > are not so easy to see. > > The layouts are described at http://lwn.net/Articles/90311/, and while > Linux usually uses the new one (described there as "top-down mmap() > method"), when RLIMIT_STACK is set to RLIM_INFINITY it falls back to the > old one (the one described first).
Hi Alberto. I was looking into this more. Although GNU make does set RLIMIT_STACK to infinity while it, itself, is running, it resets the stack size back to the original value it had when it was started before it runs any commands. That is, in job.c after we fork() to start the command we call setrlimit() again to reset the stack back to what it was, before we exec() the command we're about to run. So, I'm not sure I fully understand the implications here. Are you saying that this resetting of the stack limit back to what it was does not reset the memory layout back to using the new method in make's children, and this causes different behavior in make's children? Or that the change somehow subtly changes the behavior of _make_ in a less-than-optimal way? I'd like to understand this so we can decide how to proceed for make 3.82 which will be out very, very shortly (so if we're going to remove this we need to make that decision right now, basically). -- ------------------------------------------------------------------------------- Paul D. Smith <psm...@gnu.org> Find some GNU make tips at: http://www.gnu.org http://make.mad-scientist.net "Please remain calm...I may be mad, but I am a professional." --Mad Scientist _______________________________________________ Bug-make mailing list Bug-make@gnu.org http://lists.gnu.org/mailman/listinfo/bug-make