Wordpress-android: Crash on many versions: RuntimeException: Canvas: trying to draw too large bitmap
https://www.fabric.io/automattic/android/apps/org.wordpress.android/issues/584116ea0aeb16625b8423b7
Seems possibly related to trying to display very large images. Added the "Media" label for that reason. Feel free to remove if not relevant.
Fatal Exception: java.lang.RuntimeException: Canvas: trying to draw too large(132986880bytes) bitmap.
at android.view.DisplayListCanvas.throwIfCannotDraw(DisplayListCanvas.java:260)
at android.graphics.Canvas.drawBitmap(Canvas.java:1420)
at android.graphics.drawable.BitmapDrawable.draw(BitmapDrawable.java:545)
at android.widget.ImageView.onDraw(ImageView.java:1286)
at android.view.View.draw(View.java:18313)
at android.view.View.updateDisplayListIfDirty(View.java:17291)
at android.view.View.draw(View.java:18075)
at android.view.ViewGroup.drawChild(ViewGroup.java:3966)
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:3752)
at android.view.View.updateDisplayListIfDirty(View.java:17286)
at android.view.View.draw(View.java:18075)
at android.view.ViewGroup.drawChild(ViewGroup.java:3966)
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:3752)
at android.view.View.updateDisplayListIfDirty(View.java:17286)
at android.view.View.draw(View.java:18075)
at android.view.ViewGroup.drawChild(ViewGroup.java:3966)
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:3752)
at android.view.View.draw(View.java:18316)
at android.widget.ScrollView.draw(ScrollView.java:2774)
at android.view.View.updateDisplayListIfDirty(View.java:17291)
at android.view.View.draw(View.java:18075)
at android.view.ViewGroup.drawChild(ViewGroup.java:3966)
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:3752)
at android.view.View.updateDisplayListIfDirty(View.java:17286)
at android.view.View.draw(View.java:18075)
at android.view.ViewGroup.drawChild(ViewGroup.java:3966)
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:3752)
at android.view.View.updateDisplayListIfDirty(View.java:17286)
at android.view.View.draw(View.java:18075)
at android.view.ViewGroup.drawChild(ViewGroup.java:3966)
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:3752)
at android.view.View.updateDisplayListIfDirty(View.java:17286)
at android.view.View.draw(View.java:18075)
at android.view.ViewGroup.drawChild(ViewGroup.java:3966)
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:3752)
at android.view.View.updateDisplayListIfDirty(View.java:17286)
at android.view.View.draw(View.java:18075)
at android.view.ViewGroup.drawChild(ViewGroup.java:3966)
at android.view.ViewGroup.dispatchDraw(ViewGroup.java:3752)
at android.view.View.draw(View.java:18316)
at com.android.internal.policy.DecorView.draw(DecorView.java:850)
at android.view.View.updateDisplayListIfDirty(View.java:17291)
at android.view.ThreadedRenderer.updateViewTreeDisplayList(ThreadedRenderer.java:666)
at android.view.ThreadedRenderer.updateRootDisplayList(ThreadedRenderer.java:672)
at android.view.ThreadedRenderer.draw(ThreadedRenderer.java:780)
at android.view.ViewRootImpl.draw(ViewRootImpl.java:3093)
at android.view.ViewRootImpl.performDraw(ViewRootImpl.java:2889)
at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:2483)
at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:1490)
at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:7027)
at android.view.Choreographer$CallbackRecord.run(Choreographer.java:927)
at android.view.Choreographer.doCallbacks(Choreographer.java:702)
at android.view.Choreographer.doFrame(Choreographer.java:638)
at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:913)
at android.os.Handler.handleCallback(Handler.java:751)
at android.os.Handler.dispatchMessage(Handler.java:95)
at android.os.Looper.loop(Looper.java:154)
at android.app.ActivityThread.main(ActivityThread.java:6688)
at java.lang.reflect.Method.invoke(Method.java)
at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:1468)
at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:1358)
hypest
All 20 comments
Looking at the various logs, this appears to be an editor issue rather than a media one. I'm seeing a lot of instances of WordPress-EDITOR: Image tapped before the crash - perhaps the ImageSettingsDialogFragment is trying to load a full-sized image?
nbradbury
on 23 Apr 2017
Yes, ImageSettingsDialogFragment was loading the full picture. Closing this for now since these kind of bugs has been fixed along the way in Media prj.
daniloercoli
on 8 Jun 2017
It's still happening in 7.6. From the log (filtering on 7.6 only) I see the Me activity as the last one tracked. Maybe it's a problem displaying the profile picture?
daniloercoli
on 28 Jun 2017
Dear developers,
I am analyzing WordPress using a static code checker. I find several code regions that loading full images from URL sites. Maybe one of them is the root cause of this bug. Maybe resize the image before displaying can fix this bug, and optimize all of them can avoid potential risks. Below are the details:
(1) https://github.com/wordpress-mobile/WordPress-Android/blob/develop/WordPress/src/main/java/org/wordpress/android/ui/posts/services/AztecImageLoader.java#L25
Hope I can help improve WordPress.
struggggle
on 8 Jul 2017
Thanks for your feedback @struggggle!
Right. This is going to be changed soon. Anyway I will add a patch asap for those who already use Aztec in betas and alphas.
This should not be a problem, since downloadBitmap is always called with a Photon URL. Photon pictures are small in size. https://github.com/wordpress-mobile/WordPress-Android/blob/develop/WordPress/src/main/java/org/wordpress/android/push/GCMMessageService.java#L578
Also downloadBitmap catches exceptions.
Right, this should not load the full size picture.
daniloercoli
on 10 Jul 2017
I my case, moving the (hi-res) splash bitmap from drawable to drawable-xxhdpi was the solution.
I had the same problem. I didn't suspect my splash screen to be the problem, since it is displayed when the app is started, but it turned out the splash screen is the problem.
The splash screen in my case has xxhdpi resolution, and it was mistakenly placed in the drawable folder, instead of drawable-xxhdpi. This made Android assume the splash screen had mdpi resolution and scale the image to 3*3 times it's required size and trying to create a bitmap.
zubairehman
on 30 Aug 2017
@hypest did you solved the problem i am facing the same problem
Fatal Exception: java.lang.RuntimeException: Canvas: trying to use a recycled bitmap android.graphics.Bitmap@6d43381
at android.graphics.Canvas.throwIfCannotDraw(Canvas.java:1271)
at android.view.DisplayListCanvas.throwIfCannotDraw(DisplayListCanvas.java:261)
at android.graphics.Canvas.drawBitmap(Canvas.java:1415)
at android.graphics.drawable.BitmapDrawable.draw(BitmapDrawable.java:528)
at android.widget.ImageView.onDraw(ImageView.java:1306)
at android.view.View.draw(View.java:17588)
at android.view.View.updateDisplayListIfDirty(View.java:16527)
at android.view.View.draw(View.java:17338)
....
mushtaq99
on 9 Aug 2018
馃憢 @mushtaq99 , I think Canvas: trying to use a recycled bitmap is most probably not related to the issue in this ticket.
hypest
on 9 Aug 2018
30-day impact: ~7 per day
Users affected: 59 in the last 30d
Last seen in: 12.6
https://sentry.io/share/issue/06479f2a38234c8abad668f173724b9f/
designsimply
on 12 Jul 2019
90-day impact: ~6 per day
Users affected in the last 90 days: 161
https://sentry.io/share/issue/06479f2a38234c8abad668f173724b9f/
designsimply
on 11 Oct 2019
90-day impact: ~7 per day
Users affected in the last 90 days: 159
https://sentry.io/share/issue/06479f2a38234c8abad668f173724b9f/
designsimply
on 6 Nov 2019
From the log (filtering on 7.6 only) I see the
Meactivity as the last one tracked. Maybe it's a problem displaying the profile picture?
I checked logs today, filtering for 13.5, and in 8 out of 13 of them it looked like a problem trying to display very large images for updated posts in the Reader. @daniloercoli I could use a gut check on that interpretation though. 馃檪
designsimply
on 14 Nov 2019
Users affected in the last 90 days: 139
https://sentry.io/share/issue/06479f2a38234c8abad668f173724b9f/
I tried these steps to trigger a crash:
- In the app, open the Reader stream for another site you're following where you can add a new post.
- On the web, go to the site and add a new post with a very large image.
- In the app, go to Reader and pull to refresh.
Result: no crash.
Can you suggest other testing scenarios to potentially try?
designsimply
on 5 Dec 2019
Users affected in the last 90 days: 154
https://sentry.io/share/issue/06479f2a38234c8abad668f173724b9f/
designsimply
on 18 Dec 2019
So based on my investigation and reading several Glide issues especially this one, I think the devices are operating in an environment with memory constraints and they are crashing when attempting to load a large image in the Reader Photo View. Currently, we are using the device's viewport to calculate the image size that should be loaded and then passing the Photon URL generated from that size to Glide. To solve this we could
- lessen the image quality.
- Calculate the memory that will be needed to load the image and check the available memory and then utilize that value to determine the options that will be used to create the bitmap in a memory-efficient way.
- Put some logs in place to get the image file size and the app's available memory into Sentry.
I haven't been able to reproduce this as yet, but I will keep on doing so. let me know if anyone has any thoughts on this so I can know if I should attempt any of the ideas I have shared.
jd-alexander
on 27 Dec 2019
Users affected in the last 90 days: 164
https://sentry.io/share/issue/06479f2a38234c8abad668f173724b9f/
designsimply
on 24 Jan 2020
An update. So I looked into this again. There's a crash I noticed that occurred because almost 15 images are present in a blog post and a user attempts to view them in the image preview. This causes 15 instances of the MediaPreviewFragment to be created and the app runs out of memory.
A solution for this case would be to limit the number of fragments that are loaded on-screen so that all instances don't have to be created especially because the user won't be viewing all the images at the same time.
jd-alexander
on 16 Mar 2020
10 events have been tracked for this crash in 14.6.1 since it was released 9d ago on Apr 22. [UPDATE: total events counted in 14.6.1 increased to 25 as of May 19.]
Number of users affected in the last 90d: 149
https://sentry.io/share/issue/06479f2a38234c8abad668f173724b9f/
designsimply
on 1 May 2020
29 events have been tracked for this crash in 14.7 since it was released 15d ago on May 4.
Number of users affected in the last 90d: 126
Number of events in the last 90d: 1300
https://sentry.io/share/issue/06479f2a38234c8abad668f173724b9f/
designsimply
on 19 May 2020
Related issues
designsimply
路
3Comments
hoverduck
路
3Comments
khaykov
路
3Comments
roundhill
路
3Comments
maxme
路
3Comments
Most helpful comment
I my case, moving the (hi-res) splash bitmap from drawable to drawable-xxhdpi was the solution.
I had the same problem. I didn't suspect my splash screen to be the problem, since it is displayed when the app is started, but it turned out the splash screen is the problem.
The splash screen in my case has xxhdpi resolution, and it was mistakenly placed in the drawable folder, instead of drawable-xxhdpi. This made Android assume the splash screen had mdpi resolution and scale the image to 3*3 times it's required size and trying to create a bitmap.