[Adium-devl] [Adium-svn] rev 22205 - trunk/Plugins/Purple Service

[Peter Hosey]

On Jan 08, 2008, at 17:19:40, Evan Schoenberg wrote:
> I didn't realize that the stack would allocate space.

Well, yeah. The pointer to that variable (&data) had to point  
*somewhere*.

> As far as I knew, malloc() was the way to allocate space.

On the heap.

More to the point, malloc is the way to allocate objects whose size  
is either:

* unknown at compile-time, or
* large.

> We use a very significant, un-regainable chunk of memory the first  
> time that method is run, and I came across that while trying to  
> figure out why.

First, OOM only tracks heap allocations.

Second, stack variables gets allocated *every* time the function is  
called, unless the variable is declared as static, in which case it's  
somewhere else.

Third, when you allocate storage on the stack (by declaring a stack  
variable), it must necessarily be of a constant size known at compile  
time. (The exception is when you use alloca to do it. OTOH, using  
alloca is “discouraged”, according to its manpage.)

If CSSM_DATA were opaque, then the only way to find out how big it is  
would have been to add code to print sizeof(CSSM_DATA).

But CSSM_DATA is not opaque. It's declared in cssmtype.h:

	typedef struct cssm_data {
	    uint32 Length; /* in bytes */
	    uint8 *Data;
	} CSSM_DATA, *CSSM_DATA_PTR;

4 + 8 = 12 bytes. It is definitely not a significant chunk of memory.  
Furthermore, if it's allocated on the stack, then it's guaranteed to  
get freed (i.e., regained) when the function exits.

Now, the bytes inside that data object (for it is basically a  
variation on the NSCFData theme) may be a significant, un-regainable  
chunk of memory. But changing how we allocate the data object itself  
does not affect that.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 186 bytes
Desc: This is a digitally signed message part
URL: <http://adium.im/pipermail/devel_adium.im/attachments/20080108/46c0bdcc/attachment.sig>