Describe the bug
Several places in the code attempt to unwrap an observed exception to get the deeper/"real" cause, e.g., in DefaultErrorCauseExtractor.extract. There are a few different flavors of this that use framework-/library-specific types as well (e.g., Quartz and Vert.x). They are all "naive" in the sense that they blindly follow the next-exception pointer without considering cycles or otherwise limiting the depth of the search. It is not common, but definitely possible that an application would accidentally create a cycle in the exception cause chain, and in this instance our instrumentation would either loop forever or cause a stack overflow. As a proof point, the JDK's Throwable.printStackTrace explicitly handles this and prints a special message about it. We probably don't need to be that fancy, as long as we don't crash the app and pick any reasonable "root cause" exception for data capture.
Steps to reproduce
exception1.initCause(exception2);
exception2.initCause(exception1);
throw exception1;
Expected behavior
At least not enter an infinite loop; ideally report a good/high-quality guess at the best data for the exception being thrown.
Actual behavior
Infinite loop/stack overflow, depending on which flavor of this in the instrumentation source is hit.
Javaagent or library instrumentation version
any
Environment
JDK:
OS:
Additional context
No response
Tip
No response
Describe the bug
Several places in the code attempt to unwrap an observed exception to get the deeper/"real" cause, e.g., in
DefaultErrorCauseExtractor.extract. There are a few different flavors of this that use framework-/library-specific types as well (e.g., Quartz and Vert.x). They are all "naive" in the sense that they blindly follow the next-exception pointer without considering cycles or otherwise limiting the depth of the search. It is not common, but definitely possible that an application would accidentally create a cycle in the exception cause chain, and in this instance our instrumentation would either loop forever or cause a stack overflow. As a proof point, the JDK'sThrowable.printStackTraceexplicitly handles this and prints a special message about it. We probably don't need to be that fancy, as long as we don't crash the app and pick any reasonable "root cause" exception for data capture.Steps to reproduce
Expected behavior
At least not enter an infinite loop; ideally report a good/high-quality guess at the best data for the exception being thrown.
Actual behavior
Infinite loop/stack overflow, depending on which flavor of this in the instrumentation source is hit.
Javaagent or library instrumentation version
any
Environment
JDK:
OS:
Additional context
No response
Tip
No response