Deadlock in interaction between flatMap, Single, and shareReplayLatestWhileConnected

[dpassage]

Using an admittedly odd combination of flatMap and shareReplayLatestWhileConnected, I managed to get my code into a deadlock condition.

Here's a short, contrived example:

    @IBAction func go(_ sender: Any) {
        print("go again!")
        disposables = DisposeBag()

        Observable.just(1)
            .flatMap { (int) -> Observable<[Int]> in
                return Observable.create { (observer) -> Disposable in
                    print("creating!")
                    // in real code, int is really an NSManagedObjectContext,
                    // and the dispatch is really moc.perform with a fetch
                    DispatchQueue.global().async {
                        observer.onNext([int])
                    }
                    sleep(1)
                    return Disposables.create()
                }
            }
            .shareReplayLatestWhileConnected()
            .subscribe { (e) in
                print(e)
            }
            .disposed(by: disposables)
    }

Put that in a single-VC iOS sample app, hook it up to a button, and hit go!

The result will be that the main thread is holding the lock in ShareReplay1WhileConnected.subscribe() and waiting on the lock in MergeSink.on to deliver the .completed event coming out of the just(1) at the top.

Meanwhile, the background dispatch queue will be holding the lock in MergeSinkIter.on (which is the same as in the parent MergeSink object) while waiting for the lock in ShareReplay1WhileConnectedConnection.on. to deliver the little array.

In real, non-contrived code, Observable.just(1) is actually a ReplaySubject which delivers an NSManagedObjectContext wrapped into a Single, and the dispatch block is really a call to NSManagedObjectContext.perform in which we do a fetch. In the real code, I was getting the deadlock about one time in 5 at my desk. The sleep above is just there to make it happen reliably; I'm sure NSManagedObjectContext.perform is actually doing a bunch of work here, plus there are a bunch of other threads in my real app.

It appears that the root cause is the background thread sneaking in to deliver the results of the computation between the next and completed events coming out of the .just.

Once I found it, I was able to work around it with proper application of .observeOn, to ensure that the connect down in the ShareReplay1WhileConnected returns immediately instead of waiting for the events. But it was a bear to find.

RxSwift/RxCocoa/RxBlocking/RxTest version/commit

RxSwift 3.5.0

Platform/Environment

• iOS 10.3

How easy is to reproduce? (chances of successful reproduce after running the self contained code)

The code above will deadlock every time; the real code was deadlocking on occasion.

Xcode version:

Version 8.3.2 (8E2002)

Installation method:

• CocoaPods

I have multiple versions of Xcode installed:
(so we can know if this is a potential cause of your issue)

• yes (Xcode 9 beta)

Level of RxSwift knowledge:
(this is so we can understand your level of knowledge
and formulate the response in an appropriate manner)

• I have a significant code base

[sergdort]

Hi, @dpassage I'm not sure if this would help with your CoreData use case, but you can try to use ContextScheduler with e.g subscribeOn

[sergdort]

I wonder why did you put sleep(1) is it to reproduce the issue or you are using it in real code?
Because it does not cause deadlock without it

[freak4pc]

@sergdort I imagine it was in order to cause a 100% reproducible example for this Deadlock.

He did state his production code looks different and that he did solve it using subscribeOn, but I would still say this is some sort of a bug as a Deadlock is definitely not the expected result here :)

[sergdort]

I feel like it's not a problem with the library, but I may be mistaken =)

The problem is that you are pushing value on another thread without leaving subscribe which is why you are getting a deadlock as NSRecursiveLock does not allow "recursive calls" from different thread

[dpassage]

@sergdort yes, the sleep(1) is only to make the reproduction reliable. The important bit is that the background thread calls onNext in the window between .just calling .onNext and .onCompleted. This allows the background thread to grab the lock in the FlatMap.

And yes, that is the root problem. Here's the thing - if I hadn't told you that the code above could deadlock, would you have given it a second thought?

[kzaher]

Hi @dpassage ,

I think we can improve this behavior.