Exception: java.io.IOException: Cannot reset

[madmed]

Hi Square team!

We are having an issue in an app, when in a listview, images on some rows load but some of them are blank. I tried to trace it and collect as much information as I can.

Exception

Picasso:Error:ImageLoadFailed:Uri http://store.indemand.com/shared/ovs/prodimages/movies/t/troublewiththecurve_ID0360906/troublewiththecurveBM_ID0360906.jpg

Picasso:Error:ImageLoadFailed:Exception java.io.IOException: Cannot reset

Picasso:Error:ImageLoadFailed:StackTrace 
[
    com.squareup.picasso.MarkableInputStream.reset(MarkableInputStream.java:94), 
    com.squareup.picasso.NetworkBitmapHunter.decodeStream(NetworkBitmapHunter.java:91), 
    com.squareup.picasso.NetworkBitmapHunter.decode(NetworkBitmapHunter.java:60), 
    com.squareup.picasso.BitmapHunter.hunt(BitmapHunter.java:111), 
    com.squareup.picasso.BitmapHunter.run(BitmapHunter.java:82), 
    java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:390),
    java.util.concurrent.FutureTask.run(FutureTask.java:234), 
    java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1080), 
    java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:573), 
    java.lang.Thread.run(Thread.java:856), 
    com.squareup.picasso.Utils$PicassoThread.run(Utils.java:218)
]

Responsible code (under getView())

pBuilder.build().load(URL).fit().into(ImageView);

By the way, I don't know if it matters but airplane mode is on, but wifi is connected. I added this because with every row loading, I am seeing this in logs:

W/Settings(4289): Setting airplane_mode_on has moved from android.provider.Settings.System to android.provider.Settings.Global, returning read-only value.

Also the app crashed with this, after scrolling through the list up and down many times;

A/Looper(4289): Could not create wake pipe.  errno=24
A/libc(4289): Fatal signal 11 (SIGSEGV) at 0xdeadbaad (code=1), thread 5091 (Picasso-Dispatc)
A/libc(4289): Unable to open connection to debuggerd: Too many open files

The app doesn't seem to crash and I also didn't see the W/Settings airplane message if I switch to

Picasso.with(_context).load(URL).fit().into(imageView);

style instead of Picasso.Builder.

[dnkoutso]

This has been an issue with various images and the quick bad solution was to increase the MARKER size in NetworkBitmapHunter.

Do you have some sample urls of images failing? Try to bump it to 131072 and see if that works.

[dnkoutso]

As for the airplane mode that seems to be OK as a warning since the API has changed. I'll verify again today.

We will be upgrading Picasso to use Gradle and API Level 19 and when we do so we will fix that warning.

[madmed]

The image is a small one: http://store.indemand.com/shared/ovs/prodimages/movies/t/troublewiththecurve_ID0360906/troublewiththecurveBM_ID0360906.jpg , around 120KB.

I couldn't see a method call to adjust the MARKER size, should I change that in source and compile my own jar?

[dnkoutso]

For now yes, I believe there is an issue filed to properly fix this.

[madmed]

I had to increase the MARKER size to 1048576 to get all sample images to show and they were small thumbnails.

[JakeWharton]

That seems like a wicked Android bug either in skia or one of the decoding libraries that it uses. We should file a bug. What version of Android?

[madmed]

Our minSDK=14 and max/targetSDK=19.

It looks like either Picasso or Android is having trouble as images get smaller. We have an even smaller thumbnail right next to the notification text when something is downloading and we weren't able to get that image to show.

[niekvse]

We're having the same issue, on all the Android phones I tested it on (4.4 and 4.3), and it only shows up when using Picasso. If I just use the BitmapFactory to create the same Bitmap (from the same source), it works fine. So, it's an issue specific to Picasso. @JakeWharton: could you elaborate on the "wicked Android bug" that you say is causing this, so we have a way to work around this? Increasing the MARKER size didn't make a difference in our case. Thanks!

[JakeWharton]

The metadata for every image format is present in the first 1024 bytes of the image. The images on which Android decides to read a ton of data on a metadata-only decode contain the relevant data in the first 1024 bytes. Something is causing the native decoding libraries to read much more data than they need to fulfill the metadata decode we are requesting.

[niekvse]

Thanks @JakeWharton! I understand the issue now. But, as far as I can see in the docs, you don't have any guarantee from the Android API's (inJustDecodeBounds) about how many bytes will be read in order to determine the image bounds. So, I don't really see how Picasso can rely on an arbitrary value (2^16; 65536) and expect it to work in all cases. It may well be an inefficient implementation on Android's part, but it seems wrong to blame them for something they don't guarantee? Additionally, even if it were a bug on Android and they fixed it, it doesn't really help Picasso users ;) (until everybody upgrades..)

[JakeWharton]

I'm looking at the implementation of bounds decoding, not the docs. It also assumes that they are in the first 1024 bytes.

[niekvse]

Thanks @JakeWharton! But how can Picasso rely on Android's implementation details? Or am I missing something? When you use their inJustDecodeBounds API to figure out the dimensions of the image, you should not rely on implementation details, but on the published java docs; i.e., the actual contract. They may change this implementation. As long as the API's don't specifically mention implementing this bounds decoding a certain way, any code using this API shouldn't rely on the implementation. So, clearly, it seems a bug in Picasso, not in Android. By following the published API, these problematic images can be loaded without problems. Can we expect this issue to be fixed in Picasso in some future release, or should we work around it ourselves somehow? Thanks again!

[JakeWharton]

It will be fixed.

On Fri, Apr 25, 2014 at 12:03 PM, niekvse notifications@github.com wrote:

Thanks @JakeWharton https://github.com/JakeWharton! But how can Picasso
rely on Android's implementation details? Or am I missing something? When
you use their inJustDecodeBounds API to figure out the dimensions of the
image, you should not rely on implementation details, but on the published
java docs; i.e., the actual contract. They may change this implementation.
As long as the API's don't specifically mention implementing this bounds
decoding a certain way, any code using this API shouldn't rely on the
implementation. So, clearly, it seems a bug in Picasso, not in Android. By
following the published API, these problematic images can be loaded without
problems. Can we expect this issue to be fixed in Picasso in some future
release, or should we work around it ourselves somehow? Thanks again!

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/364#issuecomment-41428247
.

[lidemin]

Hi, @JakeWharton . Correct me if i was wrong.

#487

I am not so sure about the original purpose of those 2 lines of codes . Seems like after I removed them this issue was gone.

Thanks.