-
Notifications
You must be signed in to change notification settings - Fork 7.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Error reporting can enter infinite loop #799
Comments
I've got a unit test that duplicates this behavior and a fix. PR coming shortly |
…CompositeException.attachCallingThreadStack
…CompositeException.attachCallingThreadStack
After further review, I still don't have a complete handle on this. The above Pull Request successfully limits the symptom of calling attachCallingThreadStack on a malformed exception, but the malformed exception is still getting created. Since I can't eliminate the malformed exception (yet), I'm submitting a Pull Request that does not call attachCallingThreadStack. This should eliminate the source of the malformed exception, with the loss of informative debugging of CompositeExceptions |
…tack when constructing a CompositeException
…tack when constructing a CompositeException
Issue #799 - Commenting out the call to attachCallingThreadStack when co...
Relevant thread dump:
java.lang.Thread.State: RUNNABLE
at java.lang.Throwable.getCause(Throwable.java:415)
- locked <0x00007f48cf6b4f20> (a java.lang.NullPointerException)
at rx.util.CompositeException.attachCallingThreadStack(CompositeException.java:87)
at rx.util.CompositeException.(CompositeException.java:42)
at rx.util.CompositeException.(CompositeException.java:51)
This is an infinite loop caused by collapsing multiple throwables together. In the presence of CompositeExceptions, we need to break out of the while-loop in CompositeException.attachCallingThreadStack on Throwables that have self-referential loops
The text was updated successfully, but these errors were encountered: