2.x: Sometimes I got a stuck while calling dispose().

[MinseongPark]

Hello,

Underlying is the stack trace while it gets stuck. Every disposables are maintained with a binder, and if the binder is killed, then the disposable also be disposed. But sometimes, it does not disposed like below even time past 10 hours. I think there's a deadlock. FYI, those disposables' dispose() can be called explicitly at another thread.

"Binder:10786_F" prio=5 tid=84 Runnable
| group="main" sCount=0 dsCount=0 flags=0 obj=0x12f04210 self=0x70abf2e800
| sysTid=18629 nice=0 cgrp=default sched=0/0 handle=0x70a83ef4f0
| state=R schedstat=( 13603466168186 263621227689 309484 ) utm=1360151 stm=194 core=6 HZ=100
| stack=0x70a82f4000-0x70a82f6000 stackSize=1009KB
| held mutexes= "mutator lock"(shared held)
at java.util.concurrent.atomic.AtomicReferenceArray.get(AtomicReferenceArray.java:124)
at io.reactivex.internal.queue.SpscLinkedArrayQueue.poll(SpscLinkedArrayQueue.java:8251)
at io.reactivex.internal.queue.SpscLinkedArrayQueue.clear(SpscLinkedArrayQueue.java:186)
at io.reactivex.internal.operators.observable.ObservableObserveOn$ObserveOnObserver.dispose(ObservableObserveOn.java:149)
at io.reactivex.internal.observers.BasicFuseableObserver.dispose(BasicFuseableObserver.java:152)
at io.reactivex.internal.observers.BasicFuseableObserver.dispose(BasicFuseableObserver.java:152)
at io.reactivex.internal.operators.observable.ObservableSampleTimed$SampleTimedObserver.dispose(ObservableSampleTimed.java:104)
at io.reactivex.observers.SerializedObserver.dispose(SerializedObserver.java:77)
at io.reactivex.internal.operators.observable.ObservableDoOnEach$DoOnEachObserver.dispose(ObservableDoOnEach.java:79)
at io.reactivex.internal.disposables.DisposableHelper.dispose(DisposableHelper.java:124)
at io.reactivex.internal.disposables.SequentialDisposable.dispose(SequentialDisposable.java:72)
at io.reactivex.internal.disposables.DisposableHelper.dispose(DisposableHelper.java:124)
at io.reactivex.internal.observers.LambdaObserver.dispose(LambdaObserver.java:102)
.... My code traces....
at android.os.BinderProxy.sendDeathNotice(Binder.java:1211)

[MinseongPark]

Please let me know if you need more info

[akarnokd]

There is a bug with cleaning up certain operators that causes an infinite loop and will be released with 2.2.14 in a few days. Till then, you can apply hide after observeOn and onBackpressureBuffer to avoid the issue.

[MinseongPark]

@akarnokd
I guess the related changes is this link.
But there is no Observable related. Underlying is my Rx code snippet.

PublishSubject.create()
.hide()
.observeOn()
.map()
.filter()
.throttleLast()
.doOnNext()
.onErrorResumeNext(Observable.empty())
.subscribe()

Whole operators' return type are Observable. Can I really avoid this issue if I add hide() after observeOn? Like below.

.observeOn()
.hide()
.map()
.....

[akarnokd]

There shouldn't be any problems with Observable. Do you have something more concrete that reproduces the hanging issue?

[MinseongPark]

@akarnokd
Currently many BGCPU issues from my app(Android) are reported to me daily which has same callstack(Described on my first question). BGCPU
issue means, BackGround CPU usage is over 10% and not getting down even time passed some hours.

I have no idea about the concrete occurrence path. Is there any way to hook there and leave some log?

[akarnokd]

I don't see how given that stacktrace. You can, of course, try and apply hide after observeOn to see the issue is resolved or not.

[akarnokd]

I found another possible race which requires observeOn in fusion mode and a 3rd thread issuing a cancellation that can lead to that infinite clear. However, your stacktrace doesn't indicate why the single observeOn operator would be in fusion mode.

Fix in #6708.

[MinseongPark]

@akarnokd
I've tried to find the reason by inspecting Observers and SpscLinkedArrayQueue. And also cannot found it. I'll let you know if the hide() is working or not. Anyway, I assume that you were supposed to isolate the QueueDisposable between ObservableObserveOn and downtream.

    public void onSubscribe(Disposable d) {
        if (DisposableHelper.validate(this.upstream, d)) {
            this.upstream = d;
            if (d instanceof QueueDisposable) {  // here

Can I know something advanced reason about it?

ps. By the way, I missed to let you know my rx java version. It is 2.2.10

[akarnokd]

Anyway, I assume that you were supposed to isolate the QueueDisposable between ObservableObserveOn and downtream.

Operators in RxJava should not just hand over the Disposable of onSubscribe to the downstream. Unfortunately, some 3rd party operators or assembly hooks do it and can cause hidden anomalies. Are you using any debug-hook library?

Can I know something advanced reason about it?

I don't understand.

[MinseongPark]

@akarnokd
No... I didn't use any debug library yet.

Can I know something advanced reason about it?

I just want to know how can it avoid the infinite loop problem in the code level after I add the hide() operator.

[akarnokd]

Yes.

[MinseongPark]

@akarnokd
The issue was still reproduced even I add hide() operator. But I just found the new changes you committed. https://github.com/ReactiveX/RxJava/commit/52dee7dbcd03ff1f6b7fa3fbc1ebdd8663d9213b
One of the test case fusedNoConcurrentCleanDueToCancel() is really similar with my situation. I'll upgrade the library version to 2.2.15 and let you know.

[nishantpardamwar]

Do we have any fix for this issue ?
We are also facing this same issue on v3.0.0