[cfe-dev] Static Analyzer Rocks Hard

[Brooks Davis]

On Mon, Jun 23, 2008 at 10:01:07AM -0700, Ted Kremenek wrote:
> 
> On Jun 23, 2008, at 9:11 AM, David Chisnall wrote:
> 
> > On 23 Jun 2008, at 16:23, Matthew Jimenez wrote:
> >
> >> It's been my experience that developers assume success without much
> >> thought as to the result of failure until they actually witness it.
> >> Allocation failure is especially nasty since the chances of
> >> reproducing the error is so slim, and Objective-C might be even
> >> nastier as nil is a valid receiver. So the need for a tool to check
> >> this exists, but for better or worse, I still wouldn't imagine
> >> developers to be proactive about handling such situations.
> >>
> >> Strangely enough, I have seen many developers be much more paranoid
> >> when allocating memory directly rather than through objects.
> >
> > Straying widely off topic, and so not sending this to the list, but  
> > the reason a lot of people never bother to check the return from  
> > malloc() is that, quite a few operating systems (e.g. Linux, and  
> > Darwin in some cases), malloc() will not fail if you run out of  
> > memory, only if you run out of virtual address space.  If you have  
> > no memory, it will create a page table entry with the present bit  
> > cleared and return a pointer to this.  The first time you try to  
> > access it, there will be a page fault and the kernel will try to  
> > give you some memory.  On Linux, if it fails then it will kill  
> > random processes until it can satisfy the allocation.  On OS X it  
> > will (now) pause the application that asked for the allocation and  
> > pop up a dialog box asking you to quit some applications.
> >
> > Because of this behaviour (which violates the spec, but hey),  
> > checking the return value for malloc() does nothing other than slow  
> > your code down.
> 
> Implementations of malloc and virtual memory are platform specific,  
> and failure can occur under different circumstances.
> 
> >  The only time they will be hit is when you run out of virtual  
> > address space, which is a lot more rare than running out of physical  
> > memory these days (especially on a 64-bit system, where you  
> > typically have 48 bits of virtual address space and under 40 bits of  
> > physical address space).
> 
> 
> This is not true.  For example, the iPhone has no virtual memory.   
> When you run out of memory you actually are running out of memory.   
> Checking for memory allocation failure is especially important on an  
> embedded device, particularly if there is state you want to save.

It's also the case the kernel's often don't use swappable memory and thus
know how much they have.  Even many 64-bit kernels limit the amount of
available kernel virtual address space.  Being able to check for failure
to handle error conditions will be useful to FreeBSD once we get the
point that we can run the static analysis tools on the kernel.

-- Brooks

> Further, not all OSes overcommit virtual memory.  In such cases, if  
> the available swap is less than the requested about of virtual address  
> space being allocated, memory allocation will fail (even if you have  
> plenty of available address space for the allocation).
> 
> In general, if your interest is in writing portable code, making  
> assumptions about when allocation can fail is dangerous.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20080623/40d51165/attachment.sig>