Subject: Re: brk(2) failed [internal error]: malloc problem or simply not enough memory?
To: None <current-users@netbsd.org>
From: Manuel Bouyer <bouyer@antioche.eu.org>
List: current-users
Date: 07/21/2002 22:56:16
On Sun, Jul 21, 2002 at 08:35:10PM +0200, Klaus Heinz wrote:
> Hi,
> 
> compiling Mozilla 1.0 I encountered the following error:
> 
>   cc1plus in malloc(): error: brk(2) failed [internal error]
>   nsDOMClassInfo.cpp: cc1plus in free(): warning: recursive call.
>   cc1plus in malloc(): warning: recursive call.
> 
> The last two lines repeated virtually endlessly (20 MB logfile) while the
> memory consumption of cc1plus grew.
> 
> I repeated this and had top running at the same time. When the error happened
> again, I saw this 'top' output:
> 
>   load averages:  1.26,  1.14,  1.09                                  19:57:34
>   40 processes:  2 runnable, 36 sleeping, 1 stopped, 1 on processor
>   CPU states: 21.0% user,  0.0% nice, 78.5% system,  0.5% interrupt,  0.0% idle
>   Memory: 56M Act, 22M Inact, 488K Wired, 2000K Exec, 32M File, 4368K Free
>   Swap: 101M Total, 16M Used, 85M Free
> 
>    PID USERNAME PRI NICE   SIZE   RES STATE      TIME   WCPU    CPU COMMAND
>   5008 heinz     63    0    34M   35M RUN        4:40 71.92% 71.92% cc1plus
> 
> Assuming 'top' output is somewhat to be trusted:
> 
> - The error message above (brk(2) failed) indicates a problem inside malloc().
>   But at the same time I still see about 4 MB free memory and lots of free
>   swap space. Am I too naive to expect the system to start putting pages
>   onto the disk when running low on memory?
> 
> - Shouldn't the compiler (even a C++ compiler) die more gracefully?
> 
> Removing the '-O2' flag let the compiler run, although it used about the
> same amount of memory (ca. 33 MB process size (SIZE and RES)). '-O' had
> the same result as '-O2'.
> Too bad that it's necessary to disable optimization on slow architectures.

What are the process limits ? On the sun3, it's too low to compile libc, I
have to unlimit before starting build.sh

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
--