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

URL: Summary: Segmentation fault regression in make 4.3 vs. 4.2.1 Project: make Submitted by: tpetazzoni Submitted on: Thu 10 Sep 2020 03:35:12 PM UTC Severity: 3 - Normal

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

Follow-up Comment #1, bug #59093 (project make): This is caused by stack overflow. A change introduced in commit 4f3a41c60a02f6df9fc0725698ade64825907822 prevents setting stack size if posix_spawn is used. ___ Reply to this item at:

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

Additional Item Attachment, bug #59093 (project make): File name: sv59093_set_stack_size.diffSize:0 KB ___ Reply to this item at:

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

Follow-up Comment #2, bug #59093 (project make): This patch in the attachment solves the issue. ___ Reply to this item at: ___ Message sent via Savanna

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

Follow-up Comment #3, bug #59093 (project make): I don't think I agree with this change. It's one thing for make to increase it's own stack size, but it's not good for make to be resetting the stack size of processes it starts. That could result in all sorts of issues. If the user invokes make

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

Follow-up Comment #4, bug #59093 (project make): Of course another solution is to work on reducing the stack needed by make. None of this will be cheap of course. Some ideas: switch more places from alloca() to malloc(), and/or convert some algorithms from recursive function calls to loops. I d

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

Additional Item Attachment, bug #59093 (project make): File name: defss.diff Size:2 KB ___ Reply to this item at:

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

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 p

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

Follow-up Comment #6, bug #59093 (project make): Any news about this bug ? ___ Reply to this item at: ___ Message sent via Savannah https://savannah.

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

Follow-up Comment #7, bug #59093 (project make): I don't like the idea of adding new variables to control stack limit sizes. That's just too esoteric for anyone who just wants to run make to deal with. This should be invisible to users. Given that the situation you have is not actually a large

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

Follow-up Comment #8, bug #59093 (project make): > I've added a new patch that rewrites this to be smarter and not use lots of stack. Please remove the previous patches that try to reset the stack size, and apply SV-59093-1.patch and see if that fixes your problem. I have tested the SV-59093-1.

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

Update of bug #59093 (project make): Status:None => Fixed Assigned to:None => psmith Open/Closed:Open => Closed Operating System:

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

Follow-up Comment #10, bug #59093 (project make): This bug has been fixed more than one year ago. Would it be possible to publish a new release of GNU Make that contains this fix? Even if it's a make 4.3.1 minor release, for example. Thanks! __