Skip to main content
July 19, 2011
Answered

iOS fileStream multiple uses causes insufficient resources error

  • July 19, 2011
  • 3 replies
  • 8416 views

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

This topic has been closed for replies.
Correct answer Jamie McDaniel

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.

3 replies

Known Participant
November 6, 2017

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.

Jamie McDanielCorrect answer
Participating Frequently
December 23, 2011

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.

Participating Frequently
December 27, 2011

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

July 19, 2011

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

Community Manager
July 20, 2011

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

July 20, 2011

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