Comments (5)
Thanks; it seems legitimate. I'm not completely a fan of the above fix (mostly because it adds a needless catch-all-exception block). AFAICT this should be very simple to fix: just add a request = null before the request = mCacheQueue.take() as the latter is a blocking call.
Pull requests welcome :)
from volley.
Looking more closely at the screenshot, it seems to indicate that what's holding onto the activity isn't the local variable in dispatcher loop (or at least, isn't just that), but is mCacheQueue, the queue itself. queue is a member variable of PriorityBlockingQueue which contains the contents.
If that's the leak, then I don't see how this kind of fix would resolve it. Are you testing on a device which uses Dalvik or one which uses ART? If it's the latter, then none of the analysis from that blog post should apply as it states that they never saw the issue with ART (and the stack trace from the screenshot would seem to bear that out).
It seems like a more fundamental issue to me; if you're using a heavy object (i.e. Activity) as your response listener, and that object goes away while the request is in flight, then there are a number of Volley internals like this one that will retain a reference to the request, even if you're a well-behaved client that calls cancel() on the request when that heavy object is destroyed. See also #15 (comment).
I think this is going to be a more involved change if we want to fix it. We could look into using WeakReference anywhere that we hold onto an object that might be/hold a Fragment/Activity.
In your particular case it seems like you've set the request tag (mTag) to a fragment instance; have you tried more cleanly separating your Request objects from any Fragments/Activities and seeing if that addresses your particular leak?
from volley.
I think you are correct. The problem I see is related to the queue it self. I found this issue PriorityBlockingQueue keeps hard reference to last removed element which has some example code for printing the queue after the last element has be taken. On a 4.2.2 device (Galaxy core), the last element does not seem to be nulled out, but it is on later versions of Android (tested 6.0 and 7.0). I'm not sure how to confirm that this bug exists in Android source code it self.
from volley.
Will close this, as I'm not able to provider more information or a solution at this time.
from volley.
FYI, we got a similar report in #114 with a sample app, and it seems like newer versions of Android have reintroduced the issue that was previously resolved with ART.
In summary:
-
mCacheQueue holding a reference to a request is expected while a request is in flight, and unfortunately it's not feasible to flush all references from Volley's internals on cancel(). However, if this leak is concerning, Volley 1.1.0 (pending final release) mitigates this by clearing listeners in cancel(), though you'll need to do the same in your own Request subclasses to fully mitigate the issue. So even if the Request is held longer than it needs to be, it won't hold any child references to Listeners (which are often Activities) once it has been canceled.
-
The "Java local" holding a reference is unexpected once the request is actually complete. This is the issue cited above in the linked blog post and should be worked around in Volley 1.1.0 without needing changes to apps.
from volley.
Related Issues (20)
- Unexpected response code 511 for HOT 1
- Support digest authentication HOT 2
- Type com.android.volley.Cache$Entry is defined multiple times HOT 1
- Caused by: com.android.tools.r8.utils.AbortException: Error: Program type already present: com.google.android.youtube.player.YouTubeApiServiceUtil HOT 1
- Volley unable to parse dateStr HOT 1
- setPriority() for Request HOT 1
- E/Volley: [18667] NetworkUtility.shouldRetryException: Unexpected response code 403 HOT 1
- -
- Com.android.volley.2015.05.28.jar HOT 1
- Support Proxy functionality HOT 1
- Volley: [5311] NetworkUtility.logSlowRequests: HTTP response for request=<[ ] HOT 3
- NetworkUtility.logSlowRequests: HTTP response for request=<[ ] https://www.google.com/ 0xd61ac103 NORMAL 1> [lifetime=6472], [size=159525], [rc=200], [retryCount=1]
- Fix nullability issues in Kotlin sample code HOT 4
- Pagination HOT 1
- Getting E/Volley: [19618] NetworkDispatcher.processRequest: Unhandled exception HOT 4
- pls rply me what can i do for this HOT 1
- Potential debug logging even when DEBUG is False HOT 6
- ConcurrentModificationException on cancel HOT 1
- App Crashed on Android version 4.3 java.lang.NoClassDefFoundError: com.android.volley.toolbox.Volley HOT 1
- Handle http 3xx redirects out of the box HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from volley.