RxJava2Debug causing `StackOverflowError` on too complex `CompositeException` about rxjava2debug HOT 11 OPEN

I love that test case :)

Indeed, RxJava2Debug will not drop any of the causes. That's fine for the vast majority of cases, but could be an issue for overly complex scenarios. I think RxJava2Debug should support those scenarios, though.

I'll give it a thought.
Give me a shout if you have some solution or expected-behaviour in mind; input is always welcome 👍

from rxjava2debug.

Yeah, I agree with you that those scenarios should be supported, especially because we had this kind of crashes on production already ;)

It seems that the most straightforward behavior would be to simply limit the included causes count to some reasonable number to avoid this kind of crashes. Anyway, I'll think about it and let you know if something will occur to me.

from rxjava2debug.

Well, sorry, I don't have a better idea for now. What do you think about my previous proposal?

from rxjava2debug.

So far, I see three issues:

1. StackOverflow while creating the enhanced stack
2. OOM while creating the enhanced stack
3. StackOverflow while printing using Android.Log in API 16

I understand your proposal would fix the third issue. But the that is really not a RxJava2Debug issue, but an Android issue. I don't think that is this library's responsibility to solve.

The other two issue I want to find a fix for.
The problem is that the way it is currently coded, each RxJava2 operation is treated with no knowledge of what other operations previously did. I want to think about a way to solve the issue in a way that's not specific to RxJava2Debug's use case, so I can then contribute back upstream.

I'm still thinking about the best way to solve this 🤔

from rxjava2debug.

just an update for any observers of the issue:

I'm scratching my head about how to support streams with over 95 operators in Android's VM. Can't find a way, though.
I need to continue wrapping observers so I can override onError implementations to hand the assembled stacktrace over...

I'm thinking that maybe giving the ability to disable RxJava2Debug just for a specific stream could be the way to go. Sadly, still gotta keep thinking about it.

from rxjava2debug.

Would the idea be that you would opt-out of assembly tracing on a particular large workflow to avoid the StackOverFlowException?

from rxjava2debug.

Yeah. I don't particularly like the idea, but that's the best I got now.
I'm banking on the assumption that there is just a couple of really extensive streams in the app. Is that correct?

from rxjava2debug.

The trouble is, I'd guess that those streams are the most likely to encounter a problem you'll want a trace for. I'm very interested in finding some kind of a solution for debugging async Rx workflows as well so I'll let you know if I come up with anything.

from rxjava2debug.

True. The more complex the stream is, the higher the chances of misbehaviour.
I see no other option than:

• a workaround to avoid the tools itself generating an issue
• refactoring streams to keep them simple (50 operators are fine for older devices)

Could you dig up one of the "real-world" failing streams and check how many operators it is composed of?

from rxjava2debug.

Hi,
I have encountered the same error on some specific device:

Caused by java.lang.StackOverflowError: stack size 8MB
       at java.lang.StringBuffer.append(StringBuffer.java:278)
	…

A solution I think would be to have in RxJavaAssemblyException public Throwable appendLast(Throwable ex) method only append first (N) exception(s) and be able to optionally enable this from RxJava2Debug class.
Is this library still in active development?
Thank you,
Dan I.

from rxjava2debug.

Hi @IDan14 , it was on hold until I got some more time.
I think I already tried your proposal and didn't work. I think the problem was really rxjava2-extensions, which I couldn't figure out how to solve.

I'll give your proposal a go, because tbh my memories about this are a bit fuzzy

from rxjava2debug.