[bug #59093] Segmentation fault regression in make 4.3 vs. 4.2.1

[Dmitry Goncharov]

Follow-up Comment #5, bug #59093 (project make):

The only issue i encountered with make children inheriting a high value of
RLIMIT_STACK was a 32 bit compiler running out of heap when compiling a large
file.

i attached another patch.
This patch sets stack limit to a default hardcoded value when posix_spawn is
enabled. The default is 128Mb. This deprives a 32 bit compiler of 128 Mb out
of its ~2Gb of space.

For those (if any) makefiles which need more than 128Mb of stack we can
introduce 2 new make functions "setrlimit" and "getrlimit". The makefile could
then call "setrlimit". This will relieve the users from the crash and from
having to know the reason of the crash.
Paul, if you think we should add "setrlimit" and "getrlimit" functions please
let me know, i'll submit a patch.


> If the user invokes make and the stack size they specify is too small then
maybe they should increase the stack size before invoking make (they can do
this with ulimit -s before invoking make).

The user won't know what causes the crash.


> Alternatively, maybe it's possible for make to dynamically reset the stack
limit before invoking posix_spawn().

make would have to know the amount of stack occupied to set this smaller
limit.
Also, what to do is this occupied amount is large?


> I don't see any good way to avoid function calls being recursive 

Another option is to keep recursion, but rewrite the code to allow tail call
optimization.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?59093>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/