React-native: [Serious Bug] Android Image not render after a few times of uses
It's a serious problem since the early version and never being solved.
Reloading of JS will quickly lead to this bug but it will always happen whether or not you do the reloading.
When you use back button to quit the app on android and re-launch it, the image will still not show. I think it is because Fresco will not be closed after you quit. It is running as long as your phone is on until you remove your app from the task manager of android.
This means your app will not show image after a period of time even if it doesn't have a lot of image to show.
Please give a high priority to this problem because it will never be production ready for react-native of android if the image will go away after a few times of uses.
narychen
All 90 comments
I have never once experienced this bug.
Can you show a code-example where this happens?
fab1an
on 11 Jul 2016
http://facebook.github.io/react-native/releases/0.26/docs/known-issues.html#memory-issues-with-png-images
It was reported in RN 0.26, but I found the issue has gone in RN 0.29. So I upgrade RN version to 0.29 but image issue that you described is still remained.
The file format most of images in my apps are png file. Do you think If I change image file format PNG to JPG, does it work well?
RooneyLeeSJ
on 11 Jul 2016
@RooneyLeeSJ My image is all JPG, from the camera roll
It's due to a TooManyBitmapsException in fresco. Check this https://github.com/facebook/fresco/issues/213
But it is still not working after clear the memory caches in Fresco
narychen
on 11 Jul 2016
I just want to build the Fresco from source into the react-native to debug the error. But I haven't found a way to build it with react-native. Can anyone give a suggestion?
narychen
on 11 Jul 2016
@fab1an Maybe you never once created an app that has many pictures to show.
check this issue https://github.com/facebook/react-native/issues/6649
narychen
on 11 Jul 2016
@fab1an I think the UIExplorer CameraRollExample could re-produce this problem if your mobile phone has many photos. Browse it and reload JS a few times, it may happen.
narychen
on 11 Jul 2016
@narychen What version of React Native are you using?
To build React Native from source and setting up logcat you can follow these instructions : Build React Native from source & Investigating issues with logcat.
charpeni
on 11 Jul 2016
@charpeni I have already built the ReactAndroid from source code.
I mean building fresco within ReactAndroid. I just tried it. it's really very complicated because fresco has many sub projects and android gradle cannot directly use the settings.gradle from fresco as gradle can only have a top level settings.gradle.
narychen
on 11 Jul 2016
@charpeni The bug exists from the early version of 0.15 to 0.27.2 which I am using now.
I checked source code of 0.12 and it always used fresco, so I guessed that the problem accompanied with react-native from the old days.
narychen
on 11 Jul 2016
I hope someone responsible for the Image module of ReactAndroid in facebook could come out and fix it because it has existed for really a long time and never get any attention.
But the app will lose its users if it cannot show image any longer after a not so long time use.
narychen
on 11 Jul 2016
Can you reproduce this? Does using Fresco.shutDown() like described in #8518, help?
fab1an
on 11 Jul 2016
Are you up to provide an example project with the easy reproducible bug without dependancy to
the CameraRoll photos ?
charpeni
on 11 Jul 2016
@fab1an I tried Fresco.shutDown() and imagePipeline.clearCaches(). It didn't work.
I checked the code of Fresco and didn't see any code decrease the mCount and mSize in com.facebook.imagepipeline.memory.BitmapCounter. The two property is the cause of the exception.
And further more the code of shutDown will call clearCaches but will not create a new imagepipeline if the old instance is not null. So call shutDown() will be the same with clearCaches()
narychen
on 11 Jul 2016
@charpeni When I first used react-native to create something half a year ago, I just noticed it will not render image after a few times of reloading. I didn't pay a lot of attention because I thought it may be a problem of reloading.
But now I find that the problem will still happen even if you don't reload the JS. JUST quit and launch and quit and launch repeat this action a few times. Your image will not render.
My android phone version is android 4.3 .
If you don't use CameraRoll, the image number will take a long time to accumulate to exceed the maxCount of fresco cache pool.
narychen
on 11 Jul 2016
Another issue I found https://github.com/facebook/react-native/issues/7408 caused by this bug.
So it is a bug easy to happen and reproduce.
narychen
on 11 Jul 2016
+1, this is a very big problem.
ms88privat
on 11 Jul 2016
@andreicoman11 Have you noticed this on Facebook's side?
charpeni
on 11 Jul 2016
I think I have found the reason for this, see the mentioned bug: #8711
fab1an
on 12 Jul 2016
also having this issue, this is very critical, list view with any image set is broken after few usages
sneerin
on 12 Jul 2016
I finally found something important.
I got a way to easily replace the repo Fresco with my own built one. Then I added a log in BitmapCounter.java of Fresco.
public synchronized boolean increase(Bitmap bitmap) {
final int bitmapSize = BitmapUtil.getSizeInBytes(bitmap);
if (mCount >= mMaxCount || mSize + bitmapSize > mMaxSize) {
return false;
}
mCount++;
mSize += bitmapSize;
Log.d("myfresco", "-"+mCount+"-"+mSize); ///add this===>
return true;
}
Then I found the logging is weird.
mCount and mSize could raise up and down when you browse a lot of images.
It will never exceed the mMaxCount and mMaxSize.
But when I press backButton of my android phone or just reloading JS of react-native, the mCount and mSize will start raising up from the value at when you quit or reload.
So after a few times of quit/launch or reloading, the mSize or mCount will exceed the threshold.
Then I add a method in FrescoModule.java in ReactAndroid
@ReactMethod
public void clearCache() {
ImagePipeline imagePipeline = Fresco.getImagePipeline();
imagePipeline.clearCaches();
}
And call it from JS side of react-native
Platform.OS=='android' && BackAndroid.addEventListener('hardwareBackPress', ()=>{
NativeModules.FrescoModule.clearCache();
return false;
}
});
The quit behavior will not cause mSize and mCount to accumulate. It will always start counting from zero.
It seems that when you quit the app which uses Fresco without calling clearCache, it will leak.
The problem seems to be fixed as I just thought, but no, it's not.
The pictures do could show after a few times quit/launch. But then the App will suddenly crash down. I think the memory is not truly been released by Fresco clearCache. It just decrease the count. What is happened inside should be further explored.
narychen
on 13 Jul 2016
And add clearCache at the reloading point
options.put(
mApplicationContext.getString(R.string.catalyst_reloadjs), new DevOptionHandler() {
@Override
public void onOptionSelected() {
ImagePipeline imagePipeline = Fresco.getImagePipeline();
imagePipeline.clearCaches();
handleReloadJS();
}
});
in DevSupportManagerImpl.java
The image not render problem could be solved.
But!!!!!! The Fresco leaking problem is still there, after a few times of reloading the App will crash.
narychen
on 13 Jul 2016
I'm considering to repace fresco, how to you think how hard it will be to implement?
sneerin
on 14 Jul 2016
From my experience this https://github.com/bumptech/glide works way more stable a bit slower on low end devices but no memory leaks so far and what is more important it shows images all the time not only first 3 times.
sneerin
on 14 Jul 2016
@sneerin If you want to support only modern devices, it's not hard to write an ImageLoader/Cache. If you do, give the CSP/Actor a model a try, so you won't get up in multithreading issues.
But keep in mind that Fresco has many many more features that would need a lot of time to replicate. So I think it's important that fresco, or whatever is causing these memory-issues get's fixed.
fab1an
on 14 Jul 2016
Everyone: Can you please post heap-dumps and thread-dumps, so we can check out if there are deadlocks involved etc?
fab1an
on 14 Jul 2016
Also please post your Android Version and phone manufacturer. I'm starting to think this could be a hardware-bug.
fab1an
on 14 Jul 2016
Since the thread dump is too long, I move it here https://github.com/narychen/JustForSomeInfo/issues/1
Heap Dump is here https://github.com/facebook/fresco/issues/1360
My Android version is 4.3 manufacturer OnePlus One
narychen
on 14 Jul 2016
I feel that the leak is in the native part of Fresco. But I'm not familiar with android native coding.
narychen
on 14 Jul 2016
The leak is because the finalizers who release the resources that your Gifs and WebPs use aren't called.
fab1an
on 14 Jul 2016
My app is showing the CameraRoll which is all of JPEG images. The app crash is due to memory filled with these JPEG images. I only have one small gif which is only 10k.
narychen
on 14 Jul 2016
With heapdump I mean a hprof file to analyze. (Android Studio -> Monitor -> GC -> Dump HPROF file)
fab1an
on 14 Jul 2016
@sneerin I think it is worth a try.
As you saw these days we posted the problems here, but no one in fresco or react-native team stand out to say something about it. Maybe it's too busy to work in facebook. We should play on our own.
narychen
on 15 Jul 2016
@sneerin @narychen Writing a new library will take weeks and require the same knowledge that you'd need to fix the issues in Fresco. So better creating a PR for that.
Another option would be to incorporate Picasso from Square into RN: https://square.github.io/picasso/
But I still want to get to the bottom of this issue: Can you do me a favor and install https://github.com/square/leakcanary so that we can find out where the code leaks?
fab1an
on 15 Jul 2016
@fab1an I feel that the leak is in the native side of fresco. fresco use Anonymous Shared Memory(Ashmem) to manage the memory under android 4.x.
My phone is android 4.3 and I think it must be a device specific problem so not all users met.
leakcanary can only detect the java heap and finalize also belong to this.
narychen
on 16 Jul 2016
@fab1an @sneerin As Fresco use Ashmem under Android 4.x, it has a different situation when compared to other image load library. Though it may be faster, it's more prone to bugs.
narychen
on 16 Jul 2016
yes, that's why I think fresco is not the best choice for react native project. It has 3 levels of abstraction. JS, Android Java, and some native code. Obviously it's super easy to catch an error on any level and very hard to debug.
sneerin
on 18 Jul 2016
Did anyone tried if the issue is still the case for new versions 0.30, 0.31-rc?
sneerin
on 26 Jul 2016
@sneerin It must be still there
narychen
on 27 Jul 2016
We're looking into this internally: I think we know the sources of the bug and should have a fix soon :)
astreet
on 29 Jul 2016
@astreet Great.
narychen
on 29 Jul 2016
A bit more information why this is happening:
We're able to repro this with a simple scroll view that looks like this:
<ScrollView>
<Image source={{uri: 'http://lorempixel.com/800/800/?tmp=0'}} style={{width: 400, height: 200}} />
<Image source={{uri: 'http://lorempixel.com/800/800/?tmp=1'}} style={{width: 400, height: 200}} />
<Image source={{uri: 'http://lorempixel.com/800/800/?tmp=2'}} style={{width: 400, height: 200}} />
<Image source={{uri: 'http://lorempixel.com/800/800/?tmp=3'}} style={{width: 400, height: 200}} />
<Image source={{uri: 'http://lorempixel.com/800/800/?tmp=4'}} style={{width: 400, height: 200}} />
<Image source={{uri: 'http://lorempixel.com/800/800/?tmp=5'}} style={{width: 400, height: 200}} />
<Image source={{uri: 'http://lorempixel.com/800/800/?tmp=6'}} style={{width: 400, height: 200}} />
<Image source={{uri: 'http://lorempixel.com/800/800/?tmp=7'}} style={{width: 400, height: 200}} />
<Image source={{uri: 'http://lorempixel.com/800/800/?tmp=8'}} style={{width: 400, height: 200}} />
<Image source={{uri: 'http://lorempixel.com/800/800/?tmp=9'}} style={{width: 400, height: 200}} />
<Image source={{uri: 'http://lorempixel.com/800/800/?tmp=10'}} style={{width: 400, height: 200}} />
<Image source={{uri: 'http://lorempixel.com/800/800/?tmp=11'}} style={{width: 400, height: 200}} />
<Image source={{uri: 'http://lorempixel.com/800/800/?tmp=12'}} style={{width: 400, height: 200}} />
<Image source={{uri: 'http://lorempixel.com/800/800/?tmp=13'}} style={{width: 400, height: 200}} />
<Image source={{uri: 'http://lorempixel.com/800/800/?tmp=14'}} style={{width: 400, height: 200}} />
<Image source={{uri: 'http://lorempixel.com/800/800/?tmp=15'}} style={{width: 400, height: 200}} />
<Image source={{uri: 'http://lorempixel.com/800/800/?tmp=16'}} style={{width: 400, height: 200}} />
<Image source={{uri: 'http://lorempixel.com/800/800/?tmp=17'}} style={{width: 400, height: 200}} />
<Image source={{uri: 'http://lorempixel.com/800/800/?tmp=18'}} style={{width: 400, height: 200}} />
<Image source={{uri: 'http://lorempixel.com/800/800/?tmp=19'}} style={{width: 400, height: 200}} />
</ScrollView>
If you reload a couple of times, some images might not show up any more on Android 4.3.
Now, if you take a look at the logs, you'll find a couple of finalizer calls that manually release some resources.
Normally, these finalizers should never need to clean things up if everything works correctly - but there seem to be some issues here.
CloseableReference: Finalized without closing: b1c49d00 b1c74f28 (type = NativePooledByteBuffer):
ReactNative re-initializes Fresco without cleaning up first, but Fresco should only be initialized once. We have to check if we can modify RN to just initialize once or if we have to re-initialize (and clean up) every time. As a quick hack, it's possible to just initialize Fresco once in FrescoModule, which leads to images showing up again on Android 4.3.
CloseableReference: Finalized without closing: b1bb7f40 b1c25b98 (type = CloseableStaticBitmap):
It seems that some RN views still hold on to bitmaps when the package is reloaded.
We'll continue to investigate how we can fix these issues.
oprisnik
on 1 Aug 2016
@oprisnik can you create a PR with a quick hack?
sneerin
on 6 Aug 2016
It's better to properly fix this, should be ready soon :)
oprisnik
on 6 Aug 2016
+1
having the same issue with
"react-native": "^0.28.0",
'Nexus 6 - 5.1.1'
leoabacade
on 9 Aug 2016
@oprisnik There's also the issue that Fresco doesn't free memory of it's animated images properly: https://github.com/facebook/fresco/issues/1363#issuecomment-233865933
fab1an
on 9 Aug 2016
Hasn't it solved yet?
RooneyLeeSJ
on 18 Aug 2016
Whats the status on this ? I can reproduce it exactly as the above mentioned (gallery of jpg images and activity switches)
saantiaguilera
on 18 Aug 2016
The best way is to only initialize Fresco once since right now it's always re-initialized with exactly the same configuration.
If we allow re-initialization, we might be in weird states (like it is currently) where images belong to different Fresco instances (and some of them might already be shut down or might not be able to free unused images accordingly).
oprisnik
on 25 Aug 2016
@oprisnik Do you mean this problem cannot be solved perfectly?
narychen
on 26 Aug 2016
@narychen We can solve it by initializing Fresco only once. We're currently looking into how we can make this change without breaking anything.
oprisnik
on 26 Aug 2016
@oprisnik Good news! I look forward to fixing it.
RooneyLeeSJ
on 31 Aug 2016
@oprisnik Shouldn't the whole react-native host be initialized once only (and only the Activity get created and destroyed?).
fab1an
on 31 Aug 2016
This should now be fixed with c0de1a7011846e780d9ddfb9d4427b8b17830c0a.
If you still have some issues with images not showing up or seeing finalize calls in debug logs, please let us know!
We're also going to update RN to use the latest Fresco version (v0.13.0).
Then we can use Fresco.hasBeenInitialized() instead of keeping track of the initialization status in RN's FrescoModule (since you could also manually call Fresco.initialize() somewhere outside of FrescoModule).
Thanks for your help!
@fab1an Yeah that should be the ideal behavior. But when you reload (press rr) the whole React package is recreated, including a new FrescoModule, so we need to make sure to not re-initialize Fresco in this case as well.
oprisnik
on 1 Sep 2016
@oprisnik I will test it a few weeks later because I'm focusing on some other urgent stuff.
narychen
on 3 Sep 2016
@oprisnik Could you explain where I should do? I changed source code in fresco/BUCK and fresco/FrescoModule.java as same as your commit. But I also encountered same issue...
RooneyLeeSJ
on 8 Sep 2016
@RooneyLeeSJ You should not need to change Fresco. Just use a React Native version that has my commit from above included.
oprisnik
on 8 Sep 2016
the solution is not working for my project, I changed the code just like : https://github.com/facebook/react-native/commit/c0de1a7011846e780d9ddfb9d4427b8b17830c0a
but the images are still blank as usual
"react-native": "^0.28.0",
'Nexus 6 - 5.1.1'
leoabacade
on 10 Sep 2016
@oprisnik Could it be made so that the React-package is only initialized once?
fab1an
on 10 Sep 2016
The changes in c0de1a7011846e780d9ddfb9d4427b8b17830c0a only initialize Fresco once and if you recreate a new FrescoModule, it's basically a no-op.
I don't think that you can have something like static React packages, but it should not matter.
@leoabacade Does this also reproduce with the sample I've posted above?
You also see this on Android 5.1.1? I think I could only reproduce this bug here for versions <5. Maybe it's a different issue.
Also, can you try with a more recent checkout that has my init fix? Maybe there were other issues that got fixed in the meantime.
oprisnik
on 10 Sep 2016
@oprisnik I just wondered, because of another issue: https://github.com/facebook/react-native/issues/8694#issuecomment-234563828
Is it really necessary to destroy the bridge and ReactInstanceManager when the Activity get's destroyed? Seems like a waste…
fab1an
on 10 Sep 2016
Yeah, I agree. Maybe somebody from the React Native team can explain why it needs to be destroyed. cc @astreet
oprisnik
on 10 Sep 2016
It depends on your use of RN: @foghina wrote some code that allows us to persist the ReactInstanceManager past Activity destroy which I think has been open sourced (can you chime in?)
astreet
on 13 Sep 2016
Yep, we don't destroy the ReactInstanceManager anymore. The change was introduced in 49f20f4.
foghina
on 14 Sep 2016
Hi @oprisnik
First, thanks for looking into this bug, there are many suffering it. I'm seeing blank images in my app and there is no ScrollView involved, but I decided to try 0.34.0-rc.0 to see if it fixed my issue and it doesn't.
Then, I copied your sample code with an ScrollView in my home component render method, and It has white blank spaces in between. I'm using moto g3 with Android 6.0 and it also happens in my Nexus 5x Android 6.0
I'm not sure how to differ if image has loaded (from the internet) or not, or if it's a rendering issue.
To be honest, I'm desperate to make this work so I can release my app to the world, so let me know anything I can do to help you.
Cheers,
Miguel
maraujop
on 22 Sep 2016
Ok, i've changed the ScrollView sample code to use an image of my blog and it renders correctly in the scrollview all of them. I don't think they have to be different to see the bug happening, right ?
But my image rendering bug still happens, so it's probably a different issue.
maraujop
on 22 Sep 2016
So do you have a minimal example how to repro the issue @maraujop?
oprisnik
on 22 Sep 2016
This bug is very likely related with finalizing and the memory issues. You should all do a heapdump with Android studio and check it for references to Bitmaps or whole Activities that aren't cleared.
fab1an
on 22 Sep 2016
thanks for answering so fast @oprisnik
I had been fighting to get a repro code before and today I've tried again. I've finally found what was triggering my render problems. I'm using a library called react-native-transformable-image. TransformableImage happens to call Image.getSize which happens to have several issues in Android, one of them is concurrency issues https://github.com/facebook/react-native/issues/10002
Looks like when I render several TransformableImage whose sources are local files, if Image.getSize gets triggered for only one of them, others don't get rendered. It's my understanding that getSize actually downloads the image and screws something up. If sources are remote files, they all work fine. This has been torturing me for days now.
I haven't seen this specific issue for rendering reported anywhere else, maybe I should open a new issue with this information.
Thanks @fab1an I will do, I'm having OutOfMemoryErrors too. I posted some information here https://github.com/facebook/react-native/issues/7972#issuecomment-244716091 although I'm not experienced in doing heapdumps, i will try.
Cheers,
Miguel
maraujop
on 22 Sep 2016
@oprisnik I just tested your solution. It's the same as the clearCaches() I said above. The image will render, but the memory is still not freed. After a few times of reloading or quit/launch, the app will crash for memory issue.
Here is my memory log when use your solution. You see the native heap is too large for my phone so it crashed.
$ adb shell dumpsys meminfo com.eggf -d
Applications Memory Usage (kB):
Uptime: 29793635 Realtime: 39961486
** MEMINFO in pid 19470 [com.eggf] **
Shared Private Heap Heap Heap
Pss Dirty Dirty Size Alloc Free
------ ------ ------ ------ ------ ------
Native 0 0 0 114264 110344 2315
Dalvik 66798 19640 66564 77704 68175 9529
Stack 492 0 492
Cursor 0 0 0
Ashmem 0 0 0
Other dev 204898 1400 204216
.so mmap 5734 2764 2440
.jar mmap 0 0 0
.apk mmap 319 0 0
.ttf mmap 308 0 0
.dex mmap 3748 484 64
Other mmap 16 12 4
Unknown 146379 892 146372
TOTAL 428692 25192 420152 191968 178519 11844
Objects
Views: 8285 ViewRootImpl: 1
AppContexts: 3 Activities: 1
Assets: 5 AssetManagers: 5
Local Binders: 71 Proxy Binders: 42
Death Recipients: 0
OpenSSL Sockets: 0
SQL
MEMORY_USED: 537
PAGECACHE_OVERFLOW: 143 MALLOC_SIZE: 62
DATABASES
pgsz dbsz Lookaside(b) cache Dbname
4 5540 41 110/129/3 /data/data/com.eggf/databases/RKStorage
4 184 208 857/136/16 /data/data/com.eggf/databases/50.db
4 40 17 0/123/1 /data/data/com.eggf/databases/webview.db
Asset Allocations
zip:/data/app/com.eggf-2.apk:/assets/fonts/Ionicons.ttf: 141K
zip:/data/app/com.eggf-2.apk:/assets/fonts/FontAwesome.ttf: 149K
Do you use a ScrollView? Or just simple <Image/>?
As @fab1an suggested, looking at heap dumps can give clues what is holding on to the bitmaps and how many bitmaps are still in memory.
Does this repro for you with the simple example that I've posted a while ago?
@narychen seems to be loading images from a camera roll. If you have for example a grid view of small thumbnails and you load all full resolution images, this will easily result in an OOM.
If you use a ScrollView, it's important that view recycling is turned on.
It would be great to have a simple way to repro this.
oprisnik
on 26 Sep 2016
Since most of the problems come from Fresco not properly releasing memory when ReactActivity is destroyed (via back button), would changing the behaviour of back button to not destroy the activity but to move it to background via moveTaskToBack solve most of the problem?
But ofc we'll need to trust android will kill the process when it needs more memory..
sbycrosz
on 26 Sep 2016
@oprisnik No. I'm building an IM app with cameraRoll. You could select picture from cameraRoll to send. And the app shows a lot of pictures which could be from network or local disk. And it will also show gif pictures, not only png.
Yes of course I'm using ScrollViews and ListViews. And load all full resolution images.
narychen
on 1 Oct 2016
@oprisnik One more question how to turn on recycling of view when use a ScrollView.
I set removeClippedSubviews=true of ListView. Is it working?
narychen
on 1 Oct 2016
I caught the crash exception info in Android monitor.
10-01 20:58:05.446 12594-12707/com.eggf V/unknown:NativeMemoryChunkPool: release (reuse) (object, size) = (43a2b350, 65536)
10-01 20:58:05.446 12594-12707/com.eggf V/unknown:NativeMemoryChunkPool: Used = (25, 6125568); Free = (8, 305152)
10-01 20:58:05.446 12594-12594/com.eggf V/unknown:AbstractDraweeController: controller 4372e8e0 1474: release: image: CloseableReference 4347a720
10-01 20:58:05.446 12594-12594/com.eggf V/unknown:AbstractDraweeController: controller 43b4ea88 1480: final_failed @ onFailure: failure: java.lang.RuntimeException: Failed to pin Bitmap
10-01 20:58:05.446 12594-12702/com.eggf E/CursorWindow: Could not create CursorWindow from Parcel due to error -12.
10-01 20:58:05.446 12594-12704/com.eggf E/CursorWindow: Could not create CursorWindow from Parcel due to error -12.
10-01 20:58:05.456 12594-12702/com.eggf E/CursorWindow: Could not create CursorWindow from Parcel due to error -12.
10-01 20:58:05.456 12594-12594/com.eggf V/unknown:AbstractDraweeController: controller 43c0de60 1479: set_final_result @ onNewResult: image: CloseableReference 431124b0
10-01 20:58:05.456 12594-12704/com.eggf E/CursorWindow: Could not create CursorWindow from Parcel due to error -12.
10-01 20:58:05.456 12594-12704/com.eggf E/CursorWindow: Could not create CursorWindow from Parcel due to error -12.
10-01 20:58:05.456 12594-12702/com.eggf E/CursorWindow: Could not create CursorWindow from Parcel due to error -12.
10-01 20:58:05.456 12594-12702/com.eggf E/CursorWindow: Could not create CursorWindow from Parcel due to error -12.
10-01 20:58:05.466 12594-12594/com.eggf V/unknown:AbstractDraweeController: controller 43987d70 1481: final_failed @ onFailure: failure: android.database.CursorWindowAllocationException: Cursor window could not be created from binder.
10-01 20:58:05.466 12594-12594/com.eggf V/unknown:AbstractDraweeController: controller 43d8cea8 1482: final_failed @ onFailure: failure: android.database.CursorWindowAllocationException: Cursor window could not be created from binder.
10-01 20:58:05.466 12594-12594/com.eggf V/unknown:AbstractDraweeController: controller 43cbdfc0 1483: final_failed @ onFailure: failure: android.database.CursorWindowAllocationException: Cursor window could not be created from binder.
10-01 20:58:05.476 12594-12670/com.eggf E/CursorWindow: Could not create CursorWindow from Parcel due to error -12.
10-01 20:58:05.486 12594-12670/com.eggf E/unknown:React: Exception in native call from JS
android.database.CursorWindowAllocationException: Cursor window could not be created from binder.
at android.database.CursorWindow.<init>(CursorWindow.java:133)
at android.database.CursorWindow.<init>(CursorWindow.java:41)
at android.database.CursorWindow$1.createFromParcel(CursorWindow.java:681)
at android.database.CursorWindow$1.createFromParcel(CursorWindow.java:679)
at android.database.BulkCursorDescriptor.readFromParcel(BulkCursorDescriptor.java:75)
at android.database.BulkCursorDescriptor$1.createFromParcel(BulkCursorDescriptor.java:34)
at android.database.BulkCursorDescriptor$1.createFromParcel(BulkCursorDescriptor.java:30)
at android.content.ContentProviderProxy.query(ContentProviderNative.java:388)
at android.content.ContentResolver.query(ContentResolver.java:414)
at android.content.ContentResolver.query(ContentResolver.java:357)
at com.facebook.react.modules.camera.CameraRollManager$GetPhotosTask.doInBackgroundGuarded(CameraRollManager.java:296)
at com.facebook.react.modules.camera.CameraRollManager$GetPhotosTask.doInBackgroundGuarded(CameraRollManager.java:246)
at com.facebook.react.bridge.GuardedAsyncTask.doInBackground(GuardedAsyncTask.java:34)
at com.facebook.react.bridge.GuardedAsyncTask.doInBackground(GuardedAsyncTask.java:22)
at android.os.AsyncTask$2.call(AsyncTask.java:287)
at java.util.concurrent.FutureTask.run(FutureTask.java:234)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573)
at java.lang.Thread.run(Thread.java:841)
10-01 20:58:05.576 12594-12594/com.eggf E/qdmemalloc: ion: Failed to map memory in the client: Out of memory
10-01 20:58:05.576 12594-12594/com.eggf E/qdgralloc: Could not mmap handle 0x83f64db8, fd=999 (Out of memory)
10-01 20:58:05.576 12594-12594/com.eggf E/qdgralloc: gralloc_register_buffer: gralloc_map failed
10-01 20:58:05.576 12594-12594/com.eggf W/GraphicBufferMapper: registerBuffer(0x83f64db8) failed -12 (Out of memory)
10-01 20:58:05.576 12594-12594/com.eggf E/GraphicBuffer: unflatten: registerBuffer failed: Out of memory (-12)
10-01 20:58:05.576 12594-12594/com.eggf E/qdmemalloc: ion: Failed to map memory in the client: Out of memory
10-01 20:58:05.576 12594-12594/com.eggf E/qdgralloc: Could not mmap handle 0x83f64db8, fd=999 (Out of memory)
10-01 20:58:05.576 12594-12594/com.eggf A/libc: Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 12594 (com.eggf)
And the memory dump before crashing.
adb shell dumpsys meminfo com.eggf -d
Applications Memory Usage (kB):
Uptime: 2188674 Realtime: 2188666
** MEMINFO in pid 12594 [com.eggf] **
Shared Private Heap Heap Heap
Pss Dirty Dirty Size Alloc Free
------ ------ ------ ------ ------ ------
Native 16 16 16 57060 29373 1202
Dalvik 21865 19932 21452 33780 32655 1125
Stack 396 0 396
Cursor 0 0 0
Ashmem 0 0 0
Other dev 129308 76032 91308
.so mmap 7196 2708 3316
.jar mmap 0 0 0
.apk mmap 362 0 0
.ttf mmap 295 0 0
.dex mmap 3188 488 60
Other mmap 21 12 4
Unknown 109760 984 109744
TOTAL 272407 100172 226296 90840 62028 2327
Objects
Views: 3170 ViewRootImpl: 1
AppContexts: 3 Activities: 1
Assets: 5 AssetManagers: 5
Local Binders: 14 Proxy Binders: 109
Death Recipients: 0
OpenSSL Sockets: 0
SQL
MEMORY_USED: 558
PAGECACHE_OVERFLOW: 164 MALLOC_SIZE: 62
DATABASES
pgsz dbsz Lookaside(b) cache Dbname
4 288 208 17/85/16 /data/data/com.eggf/databases/50.db
4 5544 42 2/78/3 /data/data/com.eggf/databases/RKStorage
4 40 17 0/72/1 /data/data/com.eggf/databases/webview.db
Asset Allocations
zip:/data/app/com.eggf-1.apk:/assets/fonts/Ionicons.ttf: 141K
zip:/data/app/com.eggf-1.apk:/assets/fonts/FontAwesome.ttf: 149K
It seems the memory usage is not hight. My android phone has 3G RAM.
narychen
on 1 Oct 2016
Yeah, I think this could be a problem with the scroll / list component then? I think that removeClippedSubviews=true should be correct but I'm not working on React Native. Maybe @astreet can chime in again :)
oprisnik
on 3 Oct 2016
I just ran into this issue on Android as well. Images just randomly doesn't render and the app has to be restarted to resolve the issues. Looking forward to see this issue resolved. <3
reimertz
on 8 Oct 2016
ScrollView? ListView?
oprisnik
on 8 Oct 2016
i use the 0.34.0 version of react-native and the newest version of Fresco, but this problem is still exist。
onepiece-dz
on 19 Oct 2016
@MingYe-dz I think the problem that image cannot show will not happen in 0.34.0. This has been fixed by @oprisnik . But the memory still leaks and will finally cause app crash down. Could give some screenshot of what happened in your app?
narychen
on 31 Oct 2016
I have this problem too
Poordeveloper
on 16 Nov 2016
@Poordeveloper Which version ?
narychen
on 20 Nov 2016
@narychen "react-native": "0.37.0"
Poordeveloper
on 20 Nov 2016
@Poordeveloper Could you try the FrescoModule.clearCache() I mentioned above to see if it happens ?
narychen
on 22 Nov 2016
@narychen do you solve this problem?
iamdurui
on 27 Dec 2016
@iamdurui Yeah, I think the problem has been solved.
I didn't use the method @oprisnik provided here. I use my method said above.
I haven't closed the issue because I found that the crash may happen when you browse a lot of images. But when I read the issue of this https://github.com/facebook/react-native/issues/499,
I finally feel that the crash may be not caused by the fresco but the listview implementation flaws in react-native.
So the issue could be closed.
narychen
on 28 Dec 2016
I still have the same problem. I'm using React Native 0.39.
I have bunch of images and when user clicks on one of those images it gets zoomed.
The render function is as follows :
return (
<View style={styles.container}>
<View style={styles.innerContainer}>
<View style={{ height: y_vis, width: x_vis}} onStartShouldSetResponder={this.onBullsEyeMove.bind(this)} onMoveShouldSetResponder={this.onBullsEyeMove.bind(this)} onResponderMove={this.onBullsEyeMove.bind(this)} onResponderRelease={this.onBullsEyeSet.bind(this)}>
<Image style={{position: 'absolute', top: top * -1, left: left * -1, width: p_width, height: p_height}} source={this.state.item.image} resizeMode="contain"></Image>
</View>
</View>
</View>
)
On iOS it works fine, like is should, but on android not.
Only first time it renders the photo, second time it renders white screen, without photo.
If I click on back or if I go to some other screen in the app and then come back, then it works, but also only the first time when I click, second time I get white screen.
I've tried with adding android:largeHeap to manifest, but no success.
Any idea?
Borisboky
on 30 Aug 2017
Anyone has solution for this?
sy-tian
on 13 Sep 2017
"react-native": "0..51-RC"
still exists
lhfiii
on 5 Dec 2017
It seems issue is still persist. Sometimes images does not load.
Any solution?
keermanish
on 23 Jun 2018
@keermanish please open a new issue with any details specific to your problem.
hramos
on 25 Jun 2018
Related issues
phongyewtong
·
3Comments
upbit
·
3Comments
janmonschke
·
3Comments
grabbou
·
3Comments
josev55
·
3Comments
Most helpful comment
"react-native": "0..51-RC"
still exists