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.

[yincrash]

My Moto G is making photos that run in to this bug on decoding. Is there a good way to fix existing bitmaps until a fix is in place?

[dnkoutso]

Known issue and number 1 priority for 2.5.1. No more MarkableInputStream problems.

[jacobtabak]

@dnkoutso Is there a workaround for this I could use on a fork? Also I'm trying to get some more context on the issue - you kind of commented out of the blue that it's a known issue. Is there more discussion elsewhere?

We're experiencing this problem specifically on Moto X (2nd gen) loading a full-resolution capture from the camera, using resize() to cap it at 1200x1200 px.

[dnkoutso]

@jacobtabak have you tried increasing the MARKER constant in NetworkRequestHandler? I think the constant was removed but the problem is sometimes Picasso is trying to find the dimensions of the bitmap so it doesnt decode all of it.

If you increase it it will work. We will be working on this to fix it once and for all.

[jacobtabak]

Thanks @dnkoutso,

We're loading from disk in this case, so unless that MARKER constant is also used in the FileRequestHandler, I'm not sure that will help.

We have narrowed it down to something that changed between 2.4 and 2.5.

By just reverting Picasso 2.4 (and by extension re-adding the okhttp-urlconnection dependency) the issue was resolved.

Unfortunately it's only happening on one device that I don't own (Moto X 2nd gen) so I can't really narrow down the exact change that broke it.

[sbakhtiarov]

Just fixed a similar issue in my app. Same conditions: Lollipop, ListView and Picasso for loading images in the list items. On list scroll I occasionally got SEGSEGV. And it worked on the ICS device without any issues.

Problem was in this code for setting up list item:

if (some_condition) {
    picasso.load(url).into(imageView);
} else {
    imageView.setImageResource(placeholderResId);
}

Solved with using picasso in both cases.

[dbacinski]

Same problem on Moto G(6.0) with Picasso version 2.5.2, but it works well with 2.6.0-SNAPSHOT. Picasso release is needed.

[lisandrop]

This issue is well over 2 years old. Is Picasso still actively maintained? Latest commit is from 2 months ago.

[cbruegg]

@lisandrop Here's @JakeWharton's explanation from about a month ago: https://www.reddit.com/r/androiddev/comments/4bgaci/autovalue_extensions_jake_wharton/d195t4r

Does Picasso perhaps have a regular contributor outside of Square who could be given the rights to publish updates? Just an idea.

[dimsuz]

Yeah, it's kinda sad to see this library stagnating a bit. I use it almost in all of my projects...
It's almost perfect, if not for these several bugs like this which are standing out - would be great to have at least one release with them fixed - and I'd say it can stagnate a bit more then ;)

[JakeWharton]

It'll happen eventually.

On Mon, Apr 25, 2016 at 6:00 PM dimsuz notifications@github.com wrote:

Yeah, it's kinda sad to see this library stagnating a bit. I use it almost
in all of my projects...
It's almost perfect, if not for these several bugs like this which are
standing out - would be great to have at least one release with them fixed

• and I'd say it can stagnate a bit more then ;)

—
You are receiving this because you were mentioned.

Reply to this email directly or view it on GitHub
#364 (comment)

[Maragues]

Upgrading to 2.5.3-SNAPSHOT fixes the issue. Thanks!

[martygeek]

I just upgraded to 2.5.3-SNAPSHOT as well. Fixed!

[lawloretienne]

If there is already a snapshot for 2.5.3 then does that mean v2.5.3 is coming in a few months from now?

[JakeWharton]

3.0.0 is next

…

On Mon, Jan 9, 2017 at 2:15 PM Etienne Lawlor ***@***.***> wrote: If there is already a snapshot for 2.5.3 then does that mean v2.5.3 is coming in a few months from now? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#364 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEEfXGVWR76o8qMHA0BJ7rDxXdAFdwks5rQrGcgaJpZM4BbK7L> .

[graycreate]

@martygeek @Maragues cannot found 2.5.3-SNAPSHOT , @JakeWharton When will the 3.0.0 come out?

[getsnoopy]

Could someone publish whatever code is in 2.5.3-SNAPSHOT as a release version please?

[auf1r2]

Actually wasn't fixed, still happening on 2.5.3-SNAPSHOT
... at com.squareup.picasso.TargetAction.error(TargetAction.java:49) at com.squareup.picasso.Picasso.deliverAction(Picasso.java:581) at com.squareup.picasso.Picasso.complete(Picasso.java:528) at com.squareup.picasso.Picasso$1.handleMessage(Picasso.java:117)
Unable to load Camera image from internal storage.
Picasso deliverAction(...) returns null Bitmap.

[JakeWharton]

The next version is 3.0.0-SNAPSHOT, not 2.5.3-SNAPSHOT.

…

On Thu, Feb 15, 2018 at 1:27 PM Dmitriy Lozenko ***@***.***> wrote: Actually wasn't fixed, still happening on 2.5.3-SNAPSHOT ... at com.squareup.picasso.TargetAction.error(TargetAction.java:49) at com.squareup.picasso.Picasso.deliverAction(Picasso.java:581) at com.squareup.picasso.Picasso.complete(Picasso.java:528) at com.squareup.picasso.Picasso$1.handleMessage(Picasso.java:117) Unable to load Camera image from internal storage. Picasso deliverAction(...) returns null Bitmap. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#364 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEERexTxHukTIFC2hQgiHz-qlWe_Dkks5tVHcXgaJpZM4BbK7L> .

[vianairan]

@JakeWharton gradle cannot locate the lib: compile 'com.squareup.picasso:picasso:3.0.0-SNAPSHOT'

Any suggestions? Thanks a lot

[JakeWharton]

See the README for the maven repository you must use.

…

On Thu, Feb 15, 2018 at 4:11 PM vianairan ***@***.***> wrote: @JakeWharton <https://github.com/jakewharton> gradle cannot locate the lib: compile 'com.squareup.picasso:picasso:3.0.0-SNAPSHOT' Any suggestions? Thanks a lot — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#364 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEEEeHtBBfrFDiHfXDfAS38JiDVLdDVks5tVJ14gaJpZM4BbK7L> .

[vianairan]

Thank you

[CoolMind]

Thank you! When receiving an image from camera and resizing it with:

Bitmap bitmap = Picasso.get().load(uri).resize(1000, 0).get();

got this exception on Meizu U20 (Android 6.0). Upgraded to 3.0.0-SNAPSHOT (see #1739). Also changed Picasso.with(context) to Picasso.get().

[yayaa]

Looking at the date of comments - @JakeWharton does 2.71828 version contains this fix?
Or is it still only in 3.0.0-SNAPSHOT ?

[dgoliy]

@yayaa looking into the commit history #1280 with the fix is included in 2.71828.
Changes comparison for the reference:
picasso-parent-2.5.2...2.71828

[paramrana78]

Same problem

java.io.IOException: Cannot reset
at com.squareup.picasso.MarkableInputStream.reset

and

yes Upgrading to 2.5.3-SNAPSHOT fixes the issue.

Thanks!