Stacktraces and subscribeOn/observeOn

[konmik]

RxJava in not nice when it comes to stacktraces.

The worst thing is observeOn that schedules execution on different threads. Every time we use observeOn we get our stacktrace from the process root, all the call history gets erased.

The idea is to make schedulers save the caller's stack, wrap action calls and attach the stacktrace to each exception that has been thrown by scheduled actions.

Pros:
traceable exceptions
Cons:
Performance cost
Leaks because of recursion

I think that we can have Schedulers.io(boolean trace) alternative that will save the stacktrace, so we could call it Schedules.io(DEBUG) to turn stacktracing off on production for performance critical parts.

How do you guys find this idea?

[akarnokd]

Taking a stacktrace has a 100x overhead compared to a pass-through.

This comes up from time to time but I don't see why one wants to see a stacktrace from another thread when the exception happened on the scheduler's thread. If the exception was thrown before observeOn, the stacktrace will have that thread's trace.

Could you give some examples where (I'm guessing) the code crashed after observeOn but the cause was before it?

The only thing I can think of is the following code:

Observable.<Func0>just(null).observeOn(Schedulers.computation()).map(r -> r.call()).subscribe(...)

This will crash on the computation scheduler with NPE, but the problem is in just(). How would the stack trace from the main thread inside the observeOn's inner Subscriber's onNext method help here?

[konmik]

api.fetchRequestResult()
     .compose(parse()) // a crash is here
     .subscribeOn(io())
     .observeOn(mainThread())
     .subscribe(it -> whatever);

If i have the call to parse() in different places I can't trace which place is causing the error.

[akarnokd]

I'm guessing it crashes in response to a value, right? Why not add doOnNext() with a conditional breakpoint and move it along the pipeline to see where the bad value appears?

[konmik]

Becaue I can't put a breakpoint without user's permission on a device that is located 2000 miles away?

[konmik]

I also don't care about the performance overhead in this situation because inability to fix the crash has bigger impact on my app over a 0.01 ms slowdown during a network request.

[akarnokd]

Do you have highly branching code or do you use custom Operators? If neither and assuming such stack capture exists, how does the list of operators in the pipeline help you? You have access to the source code of parse() and is unit-tested anyway, right?

[konmik]

Unit tests do not cover all possible situations, sometimes crashes happen.

parse() is just an example, I don't have such function.

[akarnokd]

I'm still having difficulty imagining a situation where a remote app crashes and you need the stacktrace all the way to the equivalent of main(String[] args) on Android. Maybe an NPE is an uncommon case. What kind of crashes do you experience?

[artem-zinnatullin]

I see the value of good stacktraces because investigating concurrency problems is usually a hard and time-consuming task.

But Schedulers.io(boolean trace) is not a scalable solution, a good one will be API in the RxJavaPlugins so you could set includeStackTraces for all schedulers, and of course, it should be part of Scheduler class so every scheduler will implement it.

// Internally we've started implementing a very similar approach for non-rx concurrency and probably will do the same for RxJava Schedulers via schedulers hook soon. Would be nice to see it in the RxJava.

@akarnokd if you afraid of overhead — this setting is dynamic, so developers will usually enable it only for debug builds or even at runtime (many projects have Developer Settings menu in the app for such options).

Real life example of hard-to-debug crash — data bus built via PublishSubject, several "writers" and one "reader" with observeOn(), when "reader" crashes — detecting what piece of code sent incorrect data to the data bus is a non-trivial task that takes some non-zero amount of time.

As far as I remember from the recordings of @benjchristensen talks about RxJava he had some thoughts on improving debugging of RxJava code, @benjchristensen what do you think about subject?

[akarnokd]

But can you know what bad data is before posting it on the event bus? If so,why not add verification to sources of the events via doOnNext() and crash the lambda?

[konmik]

Because you can not verify all cases of bad data.
You can also have a bug somewhere in the observable, for example if it parses the response itself.

[akarnokd]

RxJavaPlugin let's you decorate the Action0s so you can take and carry the stacktraces around. It appears to me that the problem is tangled with eventbus-like usage of RxJava. You can wrap your data into a structure that captures its origin information.

[konmik]

I don't think that plugins can help here - I want to have stack traces for some observables. If we inject a plugin we will be forced to always have that traces and lose the ability for recursive chain calls because of memory leaks.

[konmik]

@akarnokd No, I don't use RxJava as a bus. The problem is not tied to any specific use case, it is a general RxJava issue.