Thanks for your comments Ken. It was really good to learn about how to use
heapshots effectively, that's definitely something I'm going to use again in
future. In this case it did provide ~some~ more information on what is going on.
Just to be clear, the problem is now solved by wrapping the
On Jun 10, 2013, at 08:23 , Jonathan Taylor jonathan.tay...@glasgow.ac.uk
wrote:
However, if I understand you correctly, you are convinced that the (large)
backing buffer for the bitmap data should be being reported by Allocations.
As you can hopefully see from these screenshots, while the
On Jun 10, 2013, at 10:23 AM, Jonathan Taylor wrote:
Thanks for your comments Ken.
You're welcome.
It was really good to learn about how to use heapshots effectively, that's
definitely something I'm going to use again in future. In this case it did
provide ~some~ more information on what
On Jun 10, 2013, at 9:15 AM, Quincey Morris
quinceymor...@rivergatesoftware.com wrote:
It's quite possible that the image files are being mapped into memory, rather
than being read into allocated buffers. That would produce the results you've
described (an increase in VM usage, but no big
On Jun 7, 2013, at 9:44 AM, Jonathan Taylor jonathan.tay...@glasgow.ac.uk
wrote:
Your suggestion of the VM Tracker instrument (which I had not spotted before)
did bring up some interesting results though. These autoreleased image
buffers that were causing the problem are definitely NOT
On Jun 7, 2013, at 11:44 AM, Jonathan Taylor wrote:
So, wrapping that single line of code in an autorelease pool has fixed it.
I do think it's interesting though (and a bit worrying) that the only way I
could pinpoint the actual problem was by reading through the relevant bits of
my code
The Allocations instrument should report objects with pending autoreleases as
ordinary live objects. (Note that many objects with retain count == pending
autorelease count will be retained again before the autorelease pool pops.)
In OS X 10.8 and iOS 6 simulator, you can set environment
On 7 Jun 2013, at 6:05 AM, Jonathan Taylor jonathan.tay...@glasgow.ac.uk
wrote:
[Greg Parker:]
The Allocations instrument should report objects with pending autoreleases
as ordinary live objects
Do you happen to know if that's true of Allocations on 10.6? Is that
definitely true for
It smells like you're doing a lot of processing with temporary objects, in a
loop, without bracketing the loop body in @autoreleasepool{}, but I remember
you saying you're not.
Oh dear. Oh dear.
You are right. I know this is what everybody has been telling me all along. I
have a tiny
On 7 Jun 2013, at 11:44 AM, Jonathan Taylor jonathan.tay...@glasgow.ac.uk
wrote:
I do think it's interesting though (and a bit worrying) that the only way I
could pinpoint the actual problem was by reading through the relevant bits of
my code over and over - I wasn't able to glean any info
On Jun 7, 2013, at 9:44 AM, Jonathan Taylor jonathan.tay...@glasgow.ac.uk
wrote:
Your suggestion of the VM Tracker instrument (which I had not spotted before)
did bring up some interesting results though. These autoreleased image
buffers that were causing the problem are definitely NOT
Thankyou all for your replies. A few responses -
On 4 Jun 2013, at 16:30, Jeff Johnson wrote:
We've run into this issue in a number of apps. As a workaround, we add a
timer to the main thread and have it fire periodically. The timer's action
method does the following:
Thanks again! I've
On Jun 6, 2013, at 4:41 AM, Jonathan Taylor jonathan.tay...@glasgow.ac.uk
wrote:
As far as I can see, the Allocations tool does not report memory that is
pending release from an autorelease pool. It would be interesting to know if
there was a way of monitoring that. Re your suggestion about
On Jun 4, 2013, at 12:35 PM, Jens Alfke j...@mooseyard.com wrote:
On Jun 4, 2013, at 8:30 AM, Jeff Johnson publicpost...@lapcatsoftware.com
wrote:
The end of the event loop cycle is immediately before the beginning. Thus,
for example, if your app is in the background and not receiving
On 06/06/2013, at 11:03 AM, Jeff Johnson publicpost...@lapcatsoftware.com
wrote:
In some cases, yes, although the architecture sometimes makes that difficult.
Can you give an example?
And even code that allocates only a small amount of memory can become very
significant if it is called
Hi all,
Can anybody advise what tools I should be using to debug a particular out of
memory condition - and maybe even how I can fix it? The error that I ultimately
encounter (in a 32-bit application on Snow Leopard) is:
2013-06-03 15:44:30.271 MyApplication[25115:a0f] NSImage: Insufficient
Hi Johnny.
This is a long-standing problem with AppKit. According to the documentation,
The Application Kit creates an autorelease pool on the main thread at the
beginning of every cycle of the event loop, and drains it at the end, thereby
releasing any autoreleased objects generated while
On Jun 3, 2013, at 8:59 AM, Jonathan Taylor wrote:
...The memory usage as reported in Activity Monitor climbs higher and higher
until, if left unattended, there is apparently no more memory available.
Clicking the mouse or switching applications causes an immediate and
significant drop in
Hi Jeff,
Thanks very much for your reply. That's brilliant. I had tried playing around
with a few tricks I thought might prompt a pool drain, but to no joy. It's
great to have a bit of code that will do the job for that - I'll give it a go
tomorrow.
Cheers
Jonny
On 4 Jun 2013, at 16:30, Jeff
On Jun 3, 2013, at 8:59 AM, Jonathan Taylor jonathan.tay...@glasgow.ac.uk
wrote:
The program loads and processes a large number (~2000) image files, and I
believe that I am disposing of memory and draining autorelease pools
correctly. Running the program under ObjectAlloc, it never reports
On Jun 4, 2013, at 8:30 AM, Jeff Johnson publicpost...@lapcatsoftware.com
wrote:
The end of the event loop cycle is immediately before the beginning. Thus,
for example, if your app is in the background and not receiving events, then
the autorelease pool will not be drained.
You can work
21 matches
Mail list logo
