SIGSEGV on android 4.3 (galaxy nexus) JWR66Y #372
Comments
|
Aha! after lots of digging (tried all combinations) it seems that it's WEBP + Glide + NON-lollipop combination that makes the SIGSEGV to popup. The curious thing is that Glide + Lollipop + WEBP does work properly. For now we will use PNG + Glide for non-lollipop devices, but it would be nice to use webp at some point. Thanks a lot! |
|
I think there are some known issues with webp, at least on versions of Android prior to KitKat (although I'd thought they were mostly on 4.1). Out of curiosity if you try disabling bitmap reuse (call |
|
@sjudd can you tell me how? here's how I call Glide: I don't see a method in DrawableRequestBuilder to set the BitmapPoolAdapter |
|
Ah yes, it has to be set on |
|
sorry, but the GlideBuilder API is a bit confusing and I couldn't quickly figure out how to use it. are you able to give me the code change over this line? |
|
You can just use the deprecated methods for testing. In your main activity (before any calls to Glide.with()): @Override
public void onCreate(Bundle savedInstanceState) {
if (!Glide.isSetup()) {
Glide.setup(new GlideBuilder()
.setBitmapPool(new BitmapPoolAdapter()));
}
} |
|
That did not worked @sjudd, sorry. Here's the log from Genymotion Galaxy nexus 4.3: |
|
guys! WEBP rocks, i can't wait for this to be fixed. |
|
Try just decoding the image with BitmapFactory directly, I'd imagine you will see the same issue. If just using BitmapFactory alone works, I'll definitely look in to it more. Unfortunately if the framework can't decode the image, there isn't much we can do. I'd like to add an integration library with a webp decoder to better support the format on older versions of Android, I just haven't had time to do so (pull requests welcome :)). |
|
@sjudd what you mean? This should be plenty to decode WEBP on API level over 14: This has been working really well since 14. Not sure why glide works differently? |
|
You didn't talk about the actual image, maybe a particular image is killing Android or the difference between byte[] and InputStream API, or the options. Actually full (transparency) support is only from API 17-18 according to docs. Though I'm not sure how can they say Android 4.2.1 because:
|
|
thanks @TWiStErRob, Here's an example: http://a2.picmix.net/4843169909309440=s940.webp My Glide integration was straight forward, I only substituted the image loading call from my in-house library to Glide. I'm unsure why mine works with all devices and Glide breaks on WEBP with < 21. I'm digging more into it, but I'm afraid it may take too much time for me to find the issue while it might be trivial for someone with more knowledge in the lib to just try to loading a bunch of WEBP images and see it crashing nicely. Like I said, I decode WEBP images like this since API level 14: It works that way for sure. It has been tested on many phones. thanks again! |
|
I based my ideas on what could go wrong on how Glide reads a Bitmap (highly likely incl. webp), and it's using @sjudd please confirm my assumption, that if the problem is in Glide, it should be around there! |
|
Confirmed, there was a bug in the framework where decodeStream will crash but decodeByteArray will succeed. We can either try to detect webp images, read them into a byte array, and call decodeByteArray, or we can try to add an integration library with a newer version of the lib and jni bindings. The later is probably the right approach for Glide 4. @mufumbo I can't promise to implement this in the near future, but I can point you to the classes you'd need to modify to support converting stream -> byte array. It's non-trivial unfortunately. |
|
Thanks for digging into it @sjudd ! There's any lost in performance for glide to get the byte[] always instead of stream? That could be a quick patch for the lib? |
|
There will be some loss of performance, you'll end up allocating a lot of byte arrays which will introduce some GC related jank. Better to do that than not show the images, and hopefully we can target it to specific versions of Android. |
|
I don't understand why GC would grab the byte[] if it will be living completely inside the Bitmap object? |
|
Because what you hand in is compressed, and a new array (for pixels) will be allocated to back the Bitmap. |
|
It's not just the byte array inside the Bitmap either. To call Again converting to byte arrays and calling decodeByteArray is still probably the right thing to do to work around the framework bug, but you may want to consider using a slightly lower quality jpeg on those older platforms instead. You might end up with slightly worse quality, but for most images the difference in quality required to get an equivalent file size probably won't be super noticeable. |
|
BitmapFactory.decodeInputstream is probably creating those byte arrays anyway, isn't it? |
|
No, it doesn't read the full stream into a byte array before decoding. Even the temporary storage decodeInputStream needs can either be passed in and re-used, or is allocated natively. We've made more progress on what looks like the same issue in #392, so let's follow up there. |
Hey guys,
I'm getting this SIGSEGV exception when using glide on a galaxy nexus. The same issue doesn't happen on Genymotion and doesn't happen on my nexus 5. Any thoughts?
First I thought glide wasn't compatible with this sdk level, but in the other thread it was clarified that the compat level is 10, so I am a bit lost.
Thanks!
The text was updated successfully, but these errors were encountered: