Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Open application and select "Invalid PDF". You'lll see a lot of "FlateDecode: decoding error." messages in application output. During document scrolling or resizing application gets Memory Warnings. It's not crashing such small applcation but crashes application with active 50M of memory. Could you please investigate possible memory leaks and handle issues during invalid documents opening? It'll be great to know any way to handle such decoding exceptions in our code. Thanks in advance.
Created attachment 2436 [details]
> "FlateDecode: decoding error."
This message comes from iOS itself (CoreGraphics which handles PDF), not MonoTouch.
> Could you please investigate possible memory leaks and handle issues during invalid documents
I'll run this into Instruments to see if the leaks comes from the application, monotouch or iOS.
> It'll be great to know any way to handle such decoding exceptions in our code.
AFAIK there's no  way (even if ObjC) to handle them.
There are not really exceptions (int the .NET and even ObjC definitions) but just something "minor" that Apple decided to let you know (out of band). Generally that's the kind of thing you ask (logs) along with bug reports (hints).
 unless you keep a thread reading the logs. They are accessible, some apps do it  but I strongly advice against that.
I cannot see any leaks (except a few strdup deep down in iOS itself) using Instruments.
A large part of the (initial) memory requirement (that you won't get back) can be traced to UIFont cache and CFUrlCache. That affects the first time you show rthe QLPreviewer. Since this is cached a large part of this memory won't be returned back once you close the previewer. However it won't be allocated again if you re-use the previewer.
There's still an increase of memory when you go back and forth the main (menu) and the PDF previewer multiple times (see attached screenshot). That memory was (mostly) allocated by CoreGraphics.
This _could_ be due to the way the QLPreviewer is being used  which can prevent some events to reach it and clean up correctly.
 from https://developer.apple.com/library/ios/#documentation/NetworkingInternet/Reference/QLPreviewController_Class/Reference/Reference.html
To display a Quick Look preview controller you have two options: You can push it into view using a UINavigationController object, or can present it modally, full screen, using the presentModalViewController:animated: method of its parent class, UIViewController.
Created attachment 2453 [details]
Instruments screenshot showing memory growth after several previews
I haven't seen any difference with 2 situations:
1. I create one controller and use it every time
2. I create new instance for new file.
Memore wasn't clearing.
Sorry I'm not sure I'm following you.
a. How much memory and how do you measure it ?
Note that memory used for caching by iOS won't be reclaimed (same for ObjC apps) even if you clear/unref everything on your side.
b. It's not about how the controller is created (or reused), it's about how it's presented. IOW it's meant to be pushed or presented modally - not to be inserted into a an existing view hierarchy.
Controller containment is possible (in general) but tricky, see  and the referred WWDC video. Note that things might "look good" without following Apple requirements but things will "go bad".
I checked this and show QLPreviewController as modal window. This working different, but still have crashes and memory warnings.
This bug has been in the NEEDINFO state with no changes for the last 90 days. Can we put this back into the NEW or CONFIRMED state, or are we still awaiting response?
If there is no change in the status of this bug over the next two weeks, this bug will be marked as NORESPONSE.
This bug has not been changed from the NEEDINFO state since my previous comment, marking as RESOLVED NORESPONSE.
Please feel free to REOPEN this bug at any time if you are still experiencing the issue. Please add the requested information and set the bug back to the NEW (or CONFIRMED) state.