Question: I have just finished ridding my project of leaks, but there are still thousands of objects under the category "GeneralBlock-0". The number of net allocations is through the roof (its approaching a million as I type) but none of them are leaks and none of them have a size greater than 0 bytes. 

UPDATE & EDIT:

QuartzCore is responsible for all of the offending objects.

The responsible callers are (in order of execution per iteration of the game loop:

```
-[CALayer setPosition:]
x_hash_table_new_  // x2
hash_table_modify
-[CALayer setPosition:] // x9
-[CALayer(CALayerPrivate)_copyRenderLayer:flags:] //x13

```

When run on a device, 48 byte sized objects are allocated under GeneralBlock-64, 128, 256 etc. with these same properties as described above. This *is* unacceptable since it obviously causes a significant slow down.
This is what code in my project the problem is traced to:

```
topRow.center = CGPointMake(topRow.center.x,topRow.center.y-PIXELS_PER_FRAME);
while (nextRow = thisTopRow.below) { //stops running when thisTopRow.below is nil
    nextRow.center = CGPointMake(nextRow.center.x,nextRow.center.y-PIXELS_PER_FRAME);       
    if (nextRow.center.y+20 < 401 && !nextRow.userInteractionEnabled)
        [nextRow enableInteraction];        
    thisTopRow = nextRow;
}

```

I was under the impression that CGPoint was a type, and would be deallocated at the end of the block of code. Why is it hogging my memory? If it comes down to it, I will upload the trace file I saved in instruments for anyone interested, but I'm pretty sure I covered everything.

Answer: 
Assuming you can duplicate the behavior under the Simulator, check to make sure your application's RSIZE is not also increasing using 'top -u' in a Terminal.

This is most likely because QuartzCore has implemented its own allocator and allocation zone, but has not fully hooked into the statistics gathering mechanism that Instruments uses.

Please file a bug.
Same problem too...
Zero bytes are being allocated in simulator but in device for each method call in CALayer is raising my memory with 48 bytes .

This result in memory issues.

Murali.