NoSuchFieldException: unsubscribed #3459
Comments
|
I too have seen this issue occurring randomly. In my case it was happening while using @yyfrankyy What is scenario in your use-case? Can you share your flow of composition ? |
|
Hi. Do you use ProGuard by any chance? I'm not an expert on it but you might need to change the field retention policy. |
|
ProGuard detects and keeps fields used by |
|
@akarnokd @artem-zinnatullin we do use proguard, but keep all the staff that rx needs by @amitcse It crashed at the very beginning since the And here are some use cases, it works quite well at most of the time. I grep all the crashes related to
Some of the crashes look like this, from these two devices. they look so similar..
|
|
IDK, but I see 2 possible reasons:
@yyfrankyy can you please wrap the try {
obs.subscribe(...);
} catch (NoSuchFieldException e) {
// collect info about fields of the BooleanSubscription class
BooleanSubscription.class.getDeclaredFields(); // include it into the crash report
}Also, recently I've shipped ProGuard rules for RxJava as aar https://github.com/artem-zinnatullin/RxJavaProGuardRules, you can try to use them instead of yours. |
|
It's definitely not pro-guard, since the decompiled class code looks correct. I can also try to capture the fields in the class (thank you for the suggestion), but since I haven't reproduced the issue myself it'll take a week before I have that data. In the mean time, I think I'll just replace Atomic_FieldUpdater with Atomic_ objects, since I confirmed that it works. |
|
@artem-zinnatullin Sure, we can do this on our next release next month, will come back later. |
|
Hi, 1: 2: 3: 4: 5: Looks like Samsung introduce some specific problem on Android 5. Do you plan to apply a workaround for that? |
Replace them all with their respective Atomic* counterparts For example AtomicLongFieldUpdater -> AtomicLong Addresses ReactiveX#3459
Replace them all with their respective Atomic* counterparts For example AtomicLongFieldUpdater -> AtomicLong Addresses ReactiveX#3459
Replace them all with their respective Atomic* counterparts For example AtomicLongFieldUpdater -> AtomicLong Addresses ReactiveX#3459
|
1000+ crashes past few days in New York Times app. Hoping for @markrietveld fix to be merged soon. We are reaching out to Samsung as well to find out exactly what happened on their end. |
Replace them all with their respective Atomic* counterparts For example AtomicLongFieldUpdater -> AtomicLong Addresses ReactiveX#3459
|
Fix delivered, all AtomicXFieldUpdater changed to AtomicX classes. |
|
Hi, Any chance to have it fixed in the 1.x branch? Thanks, |
|
@roccozanni Would you be interested in fixing it? |
|
@akarnokd I can definitely give it a try. I forked the project and imported into Eclipse, but I have some troubles with the unit tests, because there are some failures and I'm not so confident in doing changes without the help of a robust existing test suites. I use RxJava since a while but I'm definitely not into the internals. Not sure if it's something misconfigured on my side (I followed the instructions in the "How to contribute" wiki page), but I can send you the JUnit xml output if needed. Can you please verify if the 1.x branch tests are working on your side? |
|
We have CI associated with the project and all the current tests pass both locally and on Travis. After you imported the project, go to the Eclipse preferences, look for Compiler warnings and set the restricted access to ignore. You should also install the Gradle IDE plugin to make sure all test dependencies are wired up properly. |
|
Same android samsung 5.0.X appeared for us with the latest 1.1.2
|
|
So those Android devices have I wonder if the |
|
I was thinking that too but I've checked and the implementation has not changed recently and we started seeing the errors just with the latest version. Pretty weird stuff... |
|
If you could play with a manual build, inlining the In the meantime, I'll try to have a System property driven way of disabling |
Replace them all with their respective Atomic* counterparts For example AtomicLongFieldUpdater -> AtomicLong Addresses ReactiveX#3459
|
I'm still having this following issue Should we replace the AtomicIntegerFieldUpdater on the class CachedThreadScheduler as well ? |
|
See #3979. |
Happened randomly, I cannot reproduce this.
Machine Info
The text was updated successfully, but these errors were encountered: