New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exception: java.io.IOException: Cannot reset #364

Closed
madmed opened this Issue Jan 20, 2014 · 70 comments

Comments

@madmed
Copy link

madmed commented Jan 20, 2014

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 comment has been minimized.

Copy link
Collaborator

dnkoutso commented Jan 21, 2014

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

This comment has been minimized.

Copy link
Collaborator

dnkoutso commented Jan 21, 2014

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

This comment has been minimized.

Copy link

madmed commented Jan 21, 2014

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

This comment has been minimized.

Copy link
Collaborator

dnkoutso commented Jan 21, 2014

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

@madmed

This comment has been minimized.

Copy link

madmed commented Jan 22, 2014

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

@JakeWharton

This comment has been minimized.

Copy link
Collaborator

JakeWharton commented Jan 22, 2014

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

This comment has been minimized.

Copy link

madmed commented Jan 23, 2014

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

This comment has been minimized.

Copy link

niekvse commented Apr 24, 2014

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

This comment has been minimized.

Copy link
Collaborator

JakeWharton commented Apr 24, 2014

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

This comment has been minimized.

Copy link

niekvse commented Apr 25, 2014

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

This comment has been minimized.

Copy link
Collaborator

JakeWharton commented Apr 25, 2014

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

@niekvse

This comment has been minimized.

Copy link

niekvse commented Apr 25, 2014

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

This comment has been minimized.

Copy link
Collaborator

JakeWharton commented Apr 25, 2014

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

This comment has been minimized.

Copy link

lidemin commented Apr 28, 2014

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

This comment has been minimized.

Copy link

yincrash commented Jun 4, 2014

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?

yincrash pushed a commit to youandmeconcierge/picasso that referenced this issue Jun 16, 2014

@dnkoutso dnkoutso modified the milestones: Picasso 2.5.1, Picasso Next Feb 12, 2015

@dnkoutso

This comment has been minimized.

Copy link
Collaborator

dnkoutso commented Feb 12, 2015

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

@jacobtabak

This comment has been minimized.

Copy link
Contributor

jacobtabak commented Feb 20, 2015

@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

This comment has been minimized.

Copy link
Collaborator

dnkoutso commented Feb 20, 2015

@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

This comment has been minimized.

Copy link
Contributor

jacobtabak commented Feb 20, 2015

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

This comment has been minimized.

Copy link

sbakhtiarov commented Mar 11, 2015

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.

@dnkoutso dnkoutso modified the milestones: Picasso 2.5.1, Picasso 2.5.2 Mar 20, 2015

@bbade

This comment has been minimized.

Copy link

bbade commented Jan 29, 2016

Also happening on my Moto G 3rd gen running M

@zewenwang

This comment has been minimized.

Copy link

zewenwang commented Mar 1, 2016

also happened on Android 5.0.2 with version 2.5.2.
when the modification will be added, and when the version 2.5.3 will be tagged

@dbacinski

This comment has been minimized.

Copy link

dbacinski commented Mar 7, 2016

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 comment has been minimized.

Copy link

lisandrop commented Apr 21, 2016

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

@cbruegg

This comment has been minimized.

Copy link

cbruegg commented Apr 22, 2016

@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

This comment has been minimized.

Copy link

dimsuz commented Apr 25, 2016

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

This comment has been minimized.

Copy link
Collaborator

JakeWharton commented Apr 25, 2016

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

This comment has been minimized.

Copy link

Maragues commented Jul 18, 2016

Upgrading to 2.5.3-SNAPSHOT fixes the issue. Thanks!

@martygeek

This comment has been minimized.

Copy link

martygeek commented Oct 28, 2016

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

@lawloretienne

This comment has been minimized.

Copy link

lawloretienne commented Jan 9, 2017

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

This comment has been minimized.

Copy link
Collaborator

JakeWharton commented Jan 9, 2017

niknetniko added a commit to ZeusWPI/hydra-android that referenced this issue Jul 30, 2017

@ghuiii

This comment has been minimized.

Copy link

ghuiii commented Sep 1, 2017

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

@getsnoopy

This comment has been minimized.

Copy link

getsnoopy commented Oct 26, 2017

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

@auf1r2

This comment has been minimized.

Copy link

auf1r2 commented Feb 15, 2018

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

This comment has been minimized.

Copy link
Collaborator

JakeWharton commented Feb 15, 2018

@vianairan

This comment has been minimized.

Copy link

vianairan commented Feb 15, 2018

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

Any suggestions? Thanks a lot

@JakeWharton

This comment has been minimized.

Copy link
Collaborator

JakeWharton commented Feb 15, 2018

@vianairan

This comment has been minimized.

Copy link

vianairan commented Feb 16, 2018

Thank you

@CoolMind

This comment has been minimized.

Copy link

CoolMind commented Feb 26, 2018

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

This comment has been minimized.

Copy link

yayaa commented Dec 28, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment