Tracking down a memory leak in my iOS app.

Q: I am having some problems with memory utilization in my iOS app.

When I run the supplied demo app PDFViewCtrlSample, everything works fine, but when I try to use ‘pdftron.PDF.PDFViewCtrl’ in my application I have problems with memory utilization and my app gets terminated.

First a question: the read me file says that I need to include the NSObjectInitWithCptr file, which I have done in my code that instantiates PDFViewCtrl. Is that right (my code is attached).

I noticed that I was having memory problems and getting more memory warnings than the demo app when opening the exact same files. I was able to avoid having my app getting terminated by calling PurgeCacheMemory from didReceiveMemoryWarning, but the demo app does not do this.

My application creates a PDFViewCtrl when a document is viewed, and then releases it when the user is finished viewing the document. From looking at this with Instruments it looks like not all of the memory is being reclaimed. Again the code is attached.

My application uses ARC, and to try to resolve these issues I set up the code that creates PDFViewCtrl to not use ARC as you will see in the attached code. It does not appear to make a difference whether I use ARC or not.


It’s good practice to call

[pdfViewCtrl CancelRendering];

[pdfViewCtrl CloseDoc];

before releasing PDFViewCtrl.

However I think you are experiencing problems because you’re allocating the control in loadView, but deallocating it in dealloc (instead of viewDidUnload). If you’re using ARC, you can just set the PDFViewCtrl to Nil in viewDidUnload. To track what’s going on, I would recommend putting NSLog statements at the beginning of the relevant methods so that you can see when they are being called. (I realize the sample project may have lead you astray here, and it will be fixed in the next version of the SDK.)

Just FYI - I was having very similar issues. The PDFViewCtrl was leaking when I would go to dismiss the controller and deallocate it.

In my case, the cause was linked to the method GetThumbAsync:.

Calling GetThumbAsync: prior to the document being set/rendered, or calling it with an invalid page number, appears to create a leak issue for the pdfViewCtrl.

Now, I check to make sure Page is valid, and wait for onRenderFinished to be called for the first time, prior to requesting GetThumbAsync:.

Hope it helps

We reproduced the problem you described when there is no document set, and this will be fixed in the next version of PDFNet. (In the meantime, please check if the doc is null before calling GetThumbAsync:). We could not reproduce the problem when calling it before the document was rendered, or when requesting a invalid page number. If you wouldn’t mind sending a small sample project to with instructions on how to reproduce the problem, we will investigate further in these cases.

Thank you!

I expect that you’re correct - it only happens when the Doc is null. I think I may have mistakenly assumed the other two scenarios (pre-render or invalid page) when the root cause was still the same, Doc was null.