Created attachment 10046 [details] Crashing pdf. pwd:1234567890123456 Hello, First of all mupdf is a great software, thanks to all participants. I downloaded latest version from git, and installed my iPad with XCode. I opened a pdf, after reading ~20 pages app crashed. There were memory warnings in the console output. But, interestingly, I downloaded the mupdf app from appstore and read that pdf without crash. I'm sending the pdf I was trying to read. It was a password protected pdf and the password is 1234567890123456. Do you have any idea?
I tried to reproduce this problem with the latest code, but didn't manage to make it happen. I realise this was reported last year, so please could you re-test with the latest code to see if the problem still occurs for you? I also ran the app under Instruments, and flicked through the first 40 pages of the document, and memory usage remained pretty stable - please see the attached screenshot. Can you confirm which verison of iPad you were using? The iPad 1 only has 256Mb of RAM, and it looks like we're quite close to that amount here (I was testing on an iPad 3). Thanks!
Created attachment 10999 [details] Screenshot of app running in Instruments
OK, I can reproduce this on an iPad 2.
I have a fix for this, which I'll push once I've had the code reviewed.
commit 13e3327167cf47aa7c202ed83835bf43169ac8c1 Author: Matt Holgate <matt@emobix.co.uk> Date: Wed Jun 18 11:10:44 2014 +0100 Fix for bug #694405 - iOS Pdf Crash If an iOS app uses too much memory, the OS asks it to free up some space. If it doesn't do so in a timely manner, it will get a second warning before being killed by the OS. In other platforms, where malloc() return NULL in OOM, the store scavenger releases memory when mallocs fail. In iOS, mallocs usually never return NULL because the app is killed before this can happen. Therefore, we need to initiate a scavenge from the low memory notification instead. We evict the store to 50% of its current size when a memory warning occurs when it is in the foreground, and 0% when a memory warning occurs whilst it is in the background. Having said this, I didn't manage to get a background warning to occur, presumably because we don't request background execution Therefore, I think in practice the OS just kills the process. However, this will be useful if we ever add background execution.