Daniel,
On Sun, Jul 23, 2000 at 12:01:53AM +0900, Daniel C. Sobral wrote:
> Mario Sergio Fujikawa Ferreira wrote:
> >
> > Backtracing showed that the problem was due
> > to the malloc function inside the get_mem function.
> > get_mem() is used to find out the largest possible memory segment.
> > It incrementaly reduces the segment passed to malloc to alloc.
> > It is the malloc function allright. It core dumps on the
> > 1st pass on get_mem(), there is no time to do_reduce. Very weird. ;(
>
> Because FreeBSD overcommits, malloc() will only fail in case of
> artificial limits being reached (like those of login.conf). If FreeBSD
> suddenly finds itself in a position of not being able to meet the
> previous commitments wrt to memory allocation, it will kill the
> application with the largest memory allocations.
>
> I'll bet you the fifth season of Babylon 5 this is what's happening. :-)
Are you willing to bet the 3rd and 4th seasons as well?
The 4th season rocks. ;-)
> Try limiting the maximum memory allocation to the total physical RAM.
The code sets limits appropriatily with RLIMIT_MEMLOCK and
RLIMIT_RSS with setrlimit().
Furthermore, I am not using any limits for the user testing
the program (a can do it all user :).
Besides, a failing malloc should return NULL, shouldn't
it? I would have expected core if I had malloc_options="X" which
I do not (in fact, I have no malloc_options).
Regards,
Mario Ferreira
ps: Perhaps you could check the code, it is only 11K long.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
