It implements a quick bug fix specifically for #376, but does not completely solve the root problem described in #419.
This problem in general is more ubiquitous, requires more complicated changes, and thus would be addressed by a separate PR.
The fix implemented in this PR wraps all methods from java.lang.StackTraceElement class into ignored sections.
This is required due to a combination of two reasons:
1) StackTraceElement own bytecode is not analyzed, but it can call methods from java.util (e.g., HashMap), which are analyzed by the Lincheck.
2) StackTraceElement methods can be called almost from any point during execution (e.g., they are called when an exeption is thrown and its stack trace is being collected).
Thus, in order to ensure that StackTraceElement code is not analyzed by the Lincheck, we need to wrap its methods into an ignored section.
This PR fixes issue #376
It implements a quick bug fix specifically for #376, but does not completely solve the root problem described in #419. This problem in general is more ubiquitous, requires more complicated changes, and thus would be addressed by a separate PR.
The fix implemented in this PR wraps all methods from
java.lang.StackTraceElementclass into ignored sections. This is required due to a combination of two reasons: 1)StackTraceElementown bytecode is not analyzed, but it can call methods fromjava.util(e.g.,HashMap), which are analyzed by the Lincheck. 2)StackTraceElementmethods can be called almost from any point during execution (e.g., they are called when an exeption is thrown and its stack trace is being collected).Thus, in order to ensure that
StackTraceElementcode is not analyzed by the Lincheck, we need to wrap its methods into an ignored section.