Update of bug #18396 (project make):
Status:None => Fixed
Assigned to:None => psmith
Open/Closed:Open => Closed
Fixed Release:
Follow-up Comment #6, bug #18396 (project make):
I've been recently caught out by setrlimit. I believe what happened is that
pthread_create (in a child process) stack size default is on linux calculated
from the stack limit.
From the pthread_create man page:
On Linux/x86-32, the
Follow-up Comment #5, bug #18396 (project make):
I think this is not an enhancement request but rather a bug-fix request.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?18396
___
Follow-up Comment #4, bug #18396 (project make):
I experienced an converse effect. I could run a program (kpdf) from shell,
but it would crash if started from make.
I used a large hard limit (~1GB) for the stack size and around 100MB as soft
limit (used it for a scientific app). My machine
However, your point about programs invoked by make inheriting the
setrlimit() is definitely something that seems problematic. Perhaps
GNU
make could change the stack limit back to what it was after it forks
but
before it execs its child. I wonder what happens if you change a
limit to
Martin Dorey wrote:
However, your point about programs invoked by make inheriting the
setrlimit() is definitely something that seems problematic. Perhaps
GNU
make could change the stack limit back to what it was after it forks
but
before it execs its child. I wonder what
Hi,
Paul D. Smith elucidated on 29/11/06 02:27:
[...]
Finally, there is no way to detect an out of stack error and exit gracefully
with a warning as you suggest: the behavior of alloca() is undefined if you
run out of stack space (it doesn't just return NULL as malloc() etc. do).
Is it
Jon Grant wrote:
My view would be that on modern computers switching to allocate from the
heap wouldn't make a big difference if it were changed. Modern heaps
have pools for small allocations to stop them fragmenting larger
allocations anyway. Someone would need to do a compressive test to know
On Wed, 2006-11-29 at 13:22 +, Jon Grant wrote:
Finally, there is no way to detect an out of stack error and exit gracefully
with a warning as you suggest: the behavior of alloca() is undefined if you
run out of stack space (it doesn't just return NULL as malloc() etc. do).
Is it
Follow-up Comment #3, bug #18396 (project make):
Regarding efficiency:
First, the main point of my report is not alloca sucks but rather
that setrlimit is an unexpected thing for make to do.
But having opened up the can of worms, let me play with them a little
(I don't really want to start a
URL:
http://savannah.gnu.org/bugs/?18396
Summary: stack size setrlimit call interacts badly with
Solaris/x86 kernel bug
Project: make
Submitted by: smcpeak
Submitted on: Tuesday 11/28/2006 at 20:16
Severity: 3 - Normal
Update of bug #18396 (project make):
Item Group: Bug = Enhancement
___
Follow-up Comment #1:
If 'make' needs to allocate a large amount (megabytes) of data,
it would be better to do so on
Follow-up Comment #2, bug #18396 (project make):
I wrote:
if large amounts of memory are needed they are allocated on the stack
Of course I meant on the _heap_ :-/.
___
Reply to this item at:
http://savannah.gnu.org/bugs/?18396
Using heap, which requires a system call to get more memory
(It doesn't affect the main point of Paul's reply but just for academic
interest) no it doesn't:
[EMAIL PROTECTED]:~/playpen$ cat ten-thousand-mallocs.c
#include stdlib.h
int main() {
for (int ii = 0; ii != 10 * 1000; ++ ii) {
On Tue, 2006-11-28 at 18:45 -0800, Martin Dorey wrote:
Using heap, which requires a system call to get more memory
(It doesn't affect the main point of Paul's reply but just for academic
interest) no it doesn't:
Even in less contrived applications, brk isn't called anything like as
often
15 matches
Mail list logo
