Date: Tue, 6 Jan 1998 14:24:45 +0000 (GMT) From: Stephen Roome <steve@visint.co.uk> To: Joel Ray Holveck <joelh@gnu.org> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Weird malloc problem. Message-ID: <Pine.BSF.3.96.980106135429.18634A-100000@dylan.visint.co.uk> In-Reply-To: <199801060618.AAA04044@detlev.UUCP>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 6 Jan 1998, Joel Ray Holveck wrote: > IIRC (and I'm no expert), it is possible to sbrk your processes' > entire addressable memory space (all 2^32 bits), and never use it. Not very logical though that I can allocate more memory than I have. To me at least. > However, when you actually try to use it, then you get a core dump (I > think a SIGSEGV). So, you call malloc, which sbrk's the block plus > its overhead. Then malloc then puts its own before the block. At > that point, then a actual page of virtual memory is assigned to the > block, not before. So, sbrk gets how much memory it can have from getrlimit, and what's happened is that I've been able to set either the soft or hard limit beyond some other more realistic limit which the vm system must already surely know about. So, does someone want to explain WHY getrlimit doesn't ask the relavent parts of the kernel before it decides what limits it will set for the user? Actually, as someone just pointed out, it's fine to set the limits to anything, but malloc should never think it suceeded in allocating virtual memory which clearly just doesn't exist! Steve -- Steve Roome - Vision Interactive Ltd. Tel:+44(0)117 9730597 Home:+44(0)976 241342 WWW: http://dylan.visint.co.uk/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.96.980106135429.18634A-100000>