Out of memory error #22
Comments
|
I haven't had any luck reproducing this. Are you able to do so reliably? If so, can you attach a heap dump (available from the debug panel in eclipse, or the monitor command line tool) from when you start seeing out of memory errors but before the application crashes? Any description of what you're doing when the oom error occurs would also be helpful (ie changing activities, scrolling a list of images etc). |
|
Since I haven't heard from you and I can't reproduce the issue, I'm going to close this for now. If you get the chance to get back to me please do reopen the ticket. |
|
I`m scrolling a listview containing 3-4 images on each listview cell. When I keep scrolling it caches the images on disc. When I reset the adapter by clearing data in the adapter and downloading it again. It will load it from cache, but as I keep scrolling the app crashes with OOM. |
|
That sounds totally plausible, though I can't seem to reproduce it. Is there any way you could provide me with a heap dump? You can can one from DDMS in eclipse, or using the 'monitor' commandline tool. Here's a blog post explaining some of the process: http://android-developers.blogspot.com/2011/03/memory-analysis-for-android.html All I would really need is the file, you don't need to run hprof-conv either. If you can provide a heap dump, try to acquire it after reseting your adapter once or twice, but before you get an OOM. Also please feel free to email me the heap dump if you'd prefer not to post it, or if you have any specific questions. My contact info is in the readme. |
|
I will mail you the heapdump once I get the OOM again. |
|
If you can reliably get the OOM exception to occur, it's best to get the heap dump just before it does. For example if scrolling up and down four times causes the exception, scroll up and down 3 times and then get the heap dump. The goal is to have some objects be leaked but not enough to cause an exception. If you acquire the heap dump just after the exception, I won't see the leak. Thanks for your help with this. |
|
allright. This occurs generally after loading several 100's of images, and reproducing it might be a bit of a trouble. I will try to get the dump ASAP. |
|
@deathlord87 Are you still seeing this? Any updates? |
|
yes,I get the error through crashlytics error/crash reporting tool. Please check |
|
So thats a 10mb image, which might be the issue. What options are you using to load the image? Can you paste your Glide.load() line? |
|
I think there's a leak with LruBitmapPool, I've seen large memories with LRUBitmapPool being like 20-30% of the whole app. I think the pool is never getting released.! is there any release logic assosiated with the LRUBitmapPool ? |
|
There is definitely release logic, but it's totally possible that it's got a bug. I'm planning on writing some unit tests for it, but if you want to try it, you may be able to uncover something sooner. It shouldn't be too hard to pattern them on the code for the lru memory cache. |
|
Added a clear memory method here: 6244968 Feel free to open a new issue if you think there might be a memory leak. |
|
Wups wrong bug! |
|
Now after adding the new jar by compiling from source-master I get the below error. |
|
Out of memory at |
|
The exact exception is more or less irrelevant, all it indicates is that you have a memory leak in your app somewhere. Bitmap or byte array allocation are larger than average and tend to be the allocations that push your app over the edge. There may or may not be a memory leak in Glide, but given the lack of reports from other users, I'd guess it's actually elsewhere in your app. Regardless I can't do much without a test app that demonstrates the problem, a heap dump, or at least some sample code... |
|
I will email you the heap dump/hprof, once the OOM crash is produced. Add me - lalith87@gmail.com The glide code which produced the crash is below Glide.load(imageurl.get(position))
.fitCenter()
.into(new DownloadImageTarget(holder,position))
.with(context);also the DownloadImageTarget class - private class DownloadImageTarget extends ImageViewTarget{
private ViewHolder holder;
/**
* Instantiates a new download image target.
*
* @param holderFromAdapter the holder from adapter
* @param position the position
*/
public DownloadImageTarget(ViewHolder holderFromAdapter,int position) {
super(holderFromAdapter.image);
holder = holderFromAdapter;
}
/* (non-Javadoc)
* @see com.bumptech.glide.presenter.target.ImageViewTarget#onImageReady(android.graphics.Bitmap)
*/
@Override
public void onImageReady(Bitmap arg0) {
Log.e(TAG, "imageReady");
// Size of image greater than 100kb, image width and image height 100px
if (arg0!=null && arg0.getHeight() > 100 && arg0.getWidth() > 100) {
holder.progressSpinner.setVisibility(View.INVISIBLE);
holder.image.setImageBitmap(arg0);
holder.imageTitle.setText(arg0.getWidth()+"x"+arg0.getHeight()+"px");
}else{
}
}
}Also it consistently crashes when loading a file from resource which takes as a full view background image on tablets (7inch and 10inch) although the same image is loaded on smaller screen sizes doesn`t cause any problem as yet. I've attached the image as well. To produce the OOM for the below image I use the code : Glide.load(R.drawable.background).into(bgImageView); |
|
Hi, I am also getting same out of memory issue in my android app and I am using Volley for network communication. While searching for the issue I stumble upon Glid. Since Glid is also using Volley at backend so I would like to share my experiance with Volley so far. I am using volley NetworkImageViewer to load the images. While i was testing my app I noticed that some of the images were not loading at all and for those images I was getting out of memory error. To rectify the problem I looked into ImageRequest class source code there I found that parseNetworkResponse has code written to efficiently load bitmap image based on maxWidth and maxHeight BUT it is never getting called because both max bounds are always zero. After changing the code partially resolved the issue but still I am getting OOM error sometime. The error comes on the method call decodeToByteArray. I hope whatever I have written makes sence as it is my first android app. |
|
There may be evident leaks in the android app(retained context,retained objects,leaky interfaces etc) which may cause OOM. However the major consumer/retained heap stayes with the Glide library's |
|
@deathlord87 I don't see anything that would cause a leak in your code. You could make it a bit more efficient by holding on to your target class in your viewholder rather than creating a new one in each call to Glide.load, but that's not a big deal. As the for the OOM with that large image, it's a problem I'd like to look in to. I'd guess it's because can only downsample in discrete quantities so the right combination of memory limit, screen size, and image dimensions could cause an overly large bitmap to be allocated. I'd suspect you can fix this by loading the same image and using: Glide.load(R.drawable.background).downsample(Downsampler.AT_MOST).into(bgImageView);Can you provide the screen size in pixels of the tablets that cause the exception? @noorulhaq Glide actually just uses volley to perform network operations, it doesn't use any of Volley's image loading code. Interesting find though, you might try to get in contact with the people who wrote volley to see if maxWidth and maxHeight being 0 is a bug in Volley's image loading code. |
|
Ok, if Glide is not using Volley for any image loading/scaling activities. Then how Glide ensures that what would be correct maximum image size (depending on device specifications) for a larger image to be loaded without any kind of crash. Thanks, |
|
@noorulhaq Glide tries to intelligently use downsampling based on the size of an image and the size of the view the image will be displayed in to avoid crashes when loading larger images. I haven't looked at Volley's code recently but from what I remember it's basically the same idea. |
|
@sjudd the device that caused the OOM is a 7" Nexus tablet and a Samsung GTP7500 10" tab |
|
@sjudd there are a lot more crashes on Android 2.3-2.3.7 devices and its raining crashes of Downsampler/ByteArrayPool (volley)/ByteArrayOutputStream crash as OOM. |
|
@deathlord87 As we discussed over email, I think there's a memory leak in your app, and Glide is just the canary in the coalmine. You could verify that by just disabling Glide and allocating a single large (1024x1024) bitmap in onCreate of your activities and switching back and forth between screens. I'd imagine after a few screen changes you will still see an issue. |
|
@sjudd I will investigate this further, Although I tried with picasso image loading library and I'm facing some issues too. So probably the issues is due to leaks internally on my app. I shall share heapdumps through email, for clarification. Thanks for the patience. |
|
also after digging into the Picasso source code I found this piece of code which might be useful for adding for cache implementation. @TargetApi(11)
public static int getSafeMemoryCacheSize(Context context){
ActivityManager am = (ActivityManager) context.getSystemService(Context.ACTIVITY_SERVICE);
boolean largeHeap = (context.getApplicationInfo().flags & android.content.pm.ApplicationInfo.FLAG_LARGE_HEAP) != 0;
int memoryClass = am.getMemoryClass();
if (largeHeap && Build.VERSION.SDK_INT >= Build.VERSION_CODES.HONEYCOMB) {
memoryClass = am.getLargeMemoryClass();
}
return (int) (1024 * 1024 * memoryClass * MEMORY_SIZE_RATIO);
}The old implementation just checks the memoryclass and doesn't check if large heap is set on the manifest. Adding the above code will help apps with large heaps to utilize glide to the optimum. |
|
The 3.0a branch has an updated memory calculator based on screen size and also as categories so you can do Glide.get(context).setMemoryCategory() to dynamically adjust the the amount of memory Glide will use. Since I haven't heard much re: the OOM exceptions, I'm going to close this for now. Feel free to reopen if you're still experiencing issues! |
|
My application uses/downloads full hd images to display on screen which was an overhead for both memory and time for download, I solved it by using GraphicMagic on the server end to resize the images to fit aspect ratio based sizes of 4xx X 4xx to solve this. Thanks for all the support and help |
The code on my application class is below.
The below is my stacktrace.
The text was updated successfully, but these errors were encountered: