I have a web app that loads images from a zip file, and displays them successively. The zip file can store many images. To prevent from running out of memory, the memory is managed, by cleaning the memory from previous images before showing the next image. This is done by: - setting the *buffer* to null. - revoking the object url and setting the *url* to null. This approach works well on various OSs such as *Windows, Linux, and MacOS*. **But on iOS it fails**. In the example, a set of images from a zip file is displayed in a loop, to mimic a zip file with many images. Setting the variable *doDebugMemoryLeakOn_iOS_withRevoke* to true, activates the code URL.revokeObjectURL(fileInfo.url); which causes the problem, after some time (after ~1100 images on my iPad Pro). The problem can be seen by running the program and selecting the zip file: https://cdn.jsdelivr.net/gh/avnermosh/example8_memoryLeakOn_iOS/example8_take2_3images.zip (or any other zip file with several jpeg images - the linked zip file simply contains 3 images in size of 4032x3024) At some point, the program fails with an error message: "The I/O read operation failed" This happens on various *iOS* devices (e.g. *iPad*, *iPhone8*) with various *iOS* versions (*iOS 15.2, iOS 14.8.1*) when played in various browsers (e.g. *Safari, Chrome, Firefox*) after about 1000 images. It also happens in a native iOS app that uses *WKWebView*. I suspect that there may be a problem with the *WKWebView* browser engine, which is common to all these browsers. Note: several places commented on [adjusting the Safari settings](https://developer.apple.com/forums/thread/684843) e.g. *GPU Process: Canvas Rendering* This somewhat deferred the problem but at some point the error still occurs. After the problem occurs, there is no way to recover programatically, e.g. by retrying to read the zip file entry or skipping to the next zip entry. The only solution is to select the file again. Could this indicate a bug in *WKWebView*? How can this be fixed, or worked around? Thanks p.s. I also placed the question [on stackoverflow](https://stackoverflow.com/questions/71122643/webapp-fails-in-ios-when-using-revokeobjecturl) that describes the problem in details and shows a link to the online example that demonstrates the problem.
Example that demonstrates the problem is in: https://jsfiddle.net/avnerm/vfgkdenp/18/ Use the .zip file from: https://cdn.jsdelivr.net/gh/avnermosh/example8_memoryLeakOn_iOS/example8_take2_3images.zip
To simplify the debugging I replaced loading-from-zipfile with loading-from-external-url To mimic the behavior of creating and cleaning object urls, I artifically clean the object url via revokeObjectURL, fetch the blob from the external url, and create an object url via createObjectURL Ideally there should not be any memory leak as I'm cleaning the object url, but there is. After a finite number of images (~500 on my iPadPro), the load fails. An example of the problem can be seen here: https://jsfiddle.net/avnerm/vd8cwy9g/5/
I can confirm that this problem also happens with an updated iOS version 15.3.1 This problem was also posted in Apple Development forum in: https://developer.apple.com/forums/thread/700639?login=true
Bump. Is anybody reading this bug at all?
Yes, but I have had time to investigate yet. We have a lot of incoming bug reports so I can take a bit of time for your bug to be acted on. I have just tried loading https://jsfiddle.net/avnerm/vd8cwy9g/5/ on my iPhone 12 Pro and it went to an image count of over 1000 without issue. I haven’t tried longer yet. Note that I am on iOS 15.4 beta.
Thanks for attending to this bug. I have seen the count going beyond 1000 on my newer iPad pro. It should reach 2990 and stop so I appreciate if you try again. I could also try on my side but I don't have an experimental device to load and test the beta release.
<rdar://problem/89339834>
The ticket has been touched about a week ago but aside from assigning it to rdar (I don't know what this even means) there was no other activity. This seems to me like a real problem. Is anyone looking into this problem at all? Thanks
(In reply to Avner from comment #8) > The ticket has been touched about a week ago but aside from assigning it to > rdar (I don't know what this even means) there was no other activity. > This seems to me like a real problem. > Is anyone looking into this problem at all? > Thanks It doesn't reproduce on the iOS Beta. I just tried https://jsfiddle.net/avnerm/vd8cwy9g/5/ again and it went up to 2990 and then stopped increasing (no crash).
This are great news. Is there a known release date for the iOS beta?
We believe this is resolved in the new iOS Beta shipped during WWDC.