Fresco: Crash in producers.LocalExifThumbnailProducer.getExifInterface

[bluef]

Hi, we got some crash report from our users

Fatal Exception: java.lang.StackOverflowError: stack size 1036KB
       at java.io.ByteArrayInputStream.read(ByteArrayInputStream.java:145)
       at android.media.ExifInterface$ByteOrderAwarenessDataInputStream.readFully(ExifInterface.java:2353)
       at android.media.ExifInterface.readImageFileDirectory(ExifInterface.java:2029)
       at android.media.ExifInterface.readImageFileDirectory(ExifInterface.java:2019)
       at android.media.ExifInterface.readImageFileDirectory(ExifInterface.java:2046)
       at android.media.ExifInterface.readImageFileDirectory(ExifInterface.java:2019)
       at android.media.ExifInterface.readImageFileDirectory(ExifInterface.java:2046)
       at android.media.ExifInterface.readImageFileDirectory(ExifInterface.java:2019)
       at android.media.ExifInterface.readImageFileDirectory(ExifInterface.java:2046)
       at android.media.ExifInterface.readImageFileDirectory(ExifInterface.java:2019)
       at android.media.ExifInterface.readImageFileDirectory(ExifInterface.java:2046)
       at android.media.ExifInterface.readImageFileDirectory(ExifInterface.java:2019)
       at android.media.ExifInterface.readImageFileDirectory(ExifInterface.java:2046)
       at android.media.ExifInterface.readImageFileDirectory(ExifInterface.java:2019)
       at android.media.ExifInterface.readImageFileDirectory(ExifInterface.java:2046)
       at android.media.ExifInterface.readImageFileDirectory(ExifInterface.java:2019)
       at android.media.ExifInterface.readImageFileDirectory(ExifInterface.java:2046)
       at android.media.ExifInterface.readImageFileDirectory(ExifInterface.java:2019)
       at android.media.ExifInterface.readImageFileDirectory(ExifInterface.java:2046)
       at android.media.ExifInterface.readImageFileDirectory(ExifInterface.java:2019)
       at android.media.ExifInterface.readImageFileDirectory(ExifInterface.java:2046)
       at android.media.ExifInterface.readImageFileDirectory(ExifInterface.java:2019)
       at android.media.ExifInterface.readImageFileDirectory(ExifInterface.java:2046)
       at android.media.ExifInterface.readImageFileDirectory(ExifInterface.java:2019)
       at android.media.ExifInterface.readExifSegment(ExifInterface.java:1868)
       at android.media.ExifInterface.getJpegAttributes(ExifInterface.java:1667)
       at android.media.ExifInterface.loadAttributes(ExifInterface.java:1334)
       at android.media.ExifInterface.(ExifInterface.java:1052)
       at com.facebook.imagepipeline.producers.LocalExifThumbnailProducer.getExifInterface(SourceFile:136)
       at com.facebook.imagepipeline.producers.LocalExifThumbnailProducer$1.getResult(SourceFile:2103)
       at com.facebook.common.executors.StatefulRunnable.run(SourceFile:45)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1112)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:587)
       at java.lang.Thread.run(Thread.java:818)

[oprisnik]

Thanks! Does this happen for specific images? Do you have a sample image where this can be reproduced with in one of our sample apps (e.g. the URI app)?
For what image format is this happening?

[bluef]

sorry those logs were collected from users and we are not able to get the images which cause the crash. And it seemed to be indroduced from fresco 1.0.0.

[bluef]

Here's the link to the crash http://crashes.to/s/b3712f643bb and wish it helps

[bluef]

hi is there any progress on this issues?

[oprisnik]

Do you have a way to reproduce this issue? The crash itself is happening in Android's ExifInterface itself, so not sure if we can do much here. We're simply creating a new ExifInterface here.
How do you use Fresco?

[bluef]

We simply use SimpleDrawee to display local picture mostly taken by users, like a gallery. Maybe adding try-catch or making getExifInterface a supplier would help developer to avoid this crash?

[badwtg1111]

Hi, I get a file that can cause this crash, you can analysis this case.

[oprisnik]

@badwtg1111 your image works for me in our Showcase sample app:

In any case, loading a bitmap this huge (the decoded bitmap has > 90 MB) is not a good idea and will crash on some devices.

[tliebeck]

Just saw this searching for other workarounds to this issue in one of my own apps. Your test image perfectly breaks things. This problem is device dependent. Crashes android.process.media as well as my own app on a Note3 with latest LineageOS. Does not crash my app or android.process.media on either a Nexus 6 with recent LineageOS or a S7 Edge (stock, latest 7.0). Already have my own trivial wrapper class for instantiating ExifInterface due to various flaws that throw RuntimeExceptions. Now catching StackOverflowError as well. Catching that is bad form of course, but it's not code I can fix.

[bluef]

@tliebeck how did you fix it?

[tliebeck]

Just made my own Exif factory class that throws a checked exception, and calling it always when I need EXIF data.. Not my favorite solution, but effective.

public static ExifInterface get(String path)
throws IOException {
    try {
        return new ExifInterface(path);
    } catch (RuntimeException | StackOverflowError ex) {
        // Internal error in Android's EXIF API.
        Log.w(FX.LOG_TAG, "Android failed to perform EXIF analysis on image: " + path + ";\n" +  ex);
        throw new IOException(ex);
    }
}

[bluef]

@tliebeck but by how did you replace the ExifInterface new instance creation code in LocalExifThumbnailProducer?

[tliebeck]

Sorry, I'm not actually using this project at all. I had the same crash behavior in one of my own Android applications (entirely unrelated to this project / not using it). Found this issue as it was the best search result. I'm only posting here to confirm it happens elsewhere and wanted to note that most devices are immune, but some are not. My solution in my own app is simply to route all calls through the above code.

[bluef]

So glad to see this issue was fixed with f38a2bc8c2b196b7e821af13595b08dd15d987dd , Thank you @franzks and @lambdapioneer