iOS fileStream multiple uses causes insufficient resources error

[Guest]

Hi All,

I've come across an issue with using the fileStream object on the iPad. The application we are writing downloads lots of data through a socket connection and we use the fileStream class to write data to the application storage directory using asyncOpen. I'm using 4.5.1 and Air2.7

All goes well for a bit , then it will hang with the error insufficient resources error. We've gone over the code, checked with the profiler to ensure the fileStream object GC and it all works fine on the windows desktop. We've even tried it on a Andriod device and its fine. But on the iPad it always hangs after a certain point.

We did some more investigation and we find that we can write 1195 files ( give or take a few ) before it crashes.  We've tried using one fileStream object, closing it, then re-using it to open another file. We've tried using a new instance of the fileStream for each file we write. We've tried batching the files in to 10,20 or 50 before disposing and using a new fileStream object.. the same thing happens and the hang occurs at the same point. We also tried some different data, just incase it was that.

My belief is that there is something wrong with the implementation for the iOS version which is not releasing the file streams at the low level. I've registered it as a bug, but I was hoping that by posting this in the forums I would...

1. Have the error confirmed by someone else. ( I'll be delighted if its just me . )

2. Raise it's awareness ( I've registered it as a bug but I get the feeling these ar'nt addressed particularly quickly ).

3. Hope that someone can offer a work around...

I've marked it as a question and will consider it answered if someone else can replicate the problem.

Many thanks

J

[Guest]

Changed my mind about the point(s) in case thats you're thing.. I'll give a helpful +5 for anyone who replictaes the issue.. and the +10 answered for anyone who comes up with a workaround

J

[sanika_Kulshreshtha]

Hi,

Could you post the bug number here? For speedy resolution, I suggest you attach your code to the bug that you have logged.

Regards,

Sanika

[Guest]

I've logged the bug under... FB-32178.

I'm afraid I cant post the code as it's part of something much larger.. In order to write a test case, I'll need to assemble something specific and my time at the moment is limited. I was hoping someone else might have had the same issue. We did find a workaround , but using open() instead of openAsync().. everything then seems to function correctly.

I would still prefer to make it all async, but this will do for now. When I get the chance I'll write a specific test I can share.

J

[derRaab___]

Boy, I'm so happy finding this post. I'm debugging a AIR for iOS Application that shows the exact same behavior. Even the download numbers are almost the same. Our App loads about 1.5 GB of data and on iPad 2 it never worked at once. iPad 3 did it.

[Jamie_McDaniel]

I switched to native iOS development.  UIKit is excellent (like Flex was in the browser) and the Objective-C syntax, although different, grows on you.  XCode is a very good IDE as well.  AIR is a great "idea" for cross platform, but Adobe just is super slow on these bugs.  I created the ticket back in December 2011.

[Guest]

Jamie helpfully filed a bug report ...

I have created a test project that illustrates the bug and filed a bug report with AIR at https://bugbase.adobe.com/index.cfm?event=bug&id=3077653

Anyone with the same issue, drop by and vote for a fix... you never know.

[develop-me]

Please Adobe fix this or create a ane dont leave us alone with this important issue!!

[leejk]

I'm running into the problem as well. This was originally reported in AIR 3.1, and now we're on 3.7 and this bug is still not fixed! It's a critical issue if you are reading and writing files to the cache directory. Any reason why this bug has been deferred for so long?

[BenLune]

I have the same problem too. Creating an app without the possibility to load many files without crashing is not possible. How is it possible that no one at Adobe give a serious answer about that bug? I spent 10 days working on this bug, activating/deactivating everything in my app... It would be great to be solved in the 3.8 version.

[Guest]

I did refile another bug at the beginning of the year.. https://bugbase.adobe.com/index.cfm?event=bug&id=3496074 for version 3.6 this has been marked as "Closed - deffered" ...

I'm not quite sure what this means in terms of timescale ( I've a sneaking suspicion its not likely to be any time soon ).. slightly more worring is the fact the priority has been set to 1-Low. .. Which I think is inappropriate given that its a hard crash and effects every app that uses async file saving. I can only think that because there is a workaround using syncronous ( open rather than openAsync ) file access to avoid the issue - it's be given this low priority. But unless you know about the poblem you're likely to use sync file operations and you'll experience what looks to be random crashes. And what if you want to do do larger file operations, the app will become unresponsive..

I wish I knew how to get this bug to be taken more seriously...

[leejk]

Yeah, I know what you mean. Personally I don't consider the alternative a work around, so like you I don't see why it's such a low priority. If the work around is so perfect then why not just remove the async commands from the API?

[Douglas McCarroll]

This is also a big problem for me. And it's not just the bug itself that's a problem. Just discovering, or trying to discover, the source of this problem is also an enormous time drain for developers. I've put in a _lot_ of hours trying to figure out why my app is freezing on iOS, and would still be doing so if I hadn't gotten lucky and noticed this thread.

[Douglas McCarroll]

Hmm...   I'm seeing similar behavior on iOS when I do asynchronous SQLite operations - i.e. using SQLConnection's openAsync() method.  Switching to open() makes the problem disappear. Does SQLConnection us FileStream's open() and openAsync() methods under the hood, or do something similar? It sure looks like it...

[nimitja]

Hi All,

The issue has been fixed and the build is available at http://labs.adobe.com/downloads/air.html, please give it a try and let us know if you will face any issue.

Regards,

Nimit

[Guest]

Holy Chiwawa !

I shall have a look today and run it through our test programs here... fingers crossed !

Many thanks !

[Guest]

Just ran my original test app using the original general released version of 3.8 a couple of times and it crashed at 4505 and 4219 files.

I then used the 3.8 beta build on labs as of yesterday (13/08/2013).. and its still going at 100,000 files !

This is AWESOME news !  it's looking very much like its fixed.

Many thanks !

J 

[nimitja]

Glad to hear.

[Jamie_McDaniel · Accepted solution]

I am seeing this issue on my iPad 2 as well.  When the app I am developing was just downloading a hundred or so images and writing them to the cache directory, it never came up.  But now each photo gallery has 100+ images, and after navigating through a few of the galleries, I get the 3005 error on fileStream.  This is with Air 3.1.  I will investigate it further and post if I find anything.

Error #3005: Insufficient system resources.

[Jamie_McDaniel]

I have created a test project that illustrates the bug and filed a bug report with AIR at https://bugbase.adobe.com/index.cfm?event=bug&id=3077653

[fullflash]

why adobe change bugbase urls for devs not reaching old bugs and vote ? )

at least you could make a redirect old urls

https://bugbase.adobe.com/index.cfm?event=bug&id=3496074  open nothing. and there is tons of such bugs that still not fixed.