-
Bug
-
Resolution: Fixed
-
Major
TreeUnmarshaller in XStream has a bug that it pushes a class onto a types stack but fails to pop it in a finally block. Then if there is an error, the context's requiredType will be bogus, which can confuse DescribableList.ConverterImpl.unmarshal as it tries to pick the right kind of list to create—it will find the type of one of the list's elements. You will end up with a ClassCastException if that type has a public no-arg constructor, or a NoSuchMethodException if it does not. The XStream bug is aggravated by the order in which the Jenkins code calls things.
Not to be confused with JENKINS-27736, which is quite different.
- relates to
-
JENKINS-49169 Investigate XStream stack unwinding behavior esp. in TreeUnmarshaller
-
- Open
-
- links to
[JENKINS-49054] Lack of finally block in TreeUnmarshaller can cause DescribableList to throw ClassCastException or NoSuchMethodException
Remote Link | New: This issue links to "XStream PR 2 (Web Link)" [ 19897 ] |
Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
Remote Link | New: This issue links to "PR 3248 (Web Link)" [ 19898 ] |
Status | Original: In Progress [ 3 ] | New: In Review [ 10005 ] |
Remote Link | New: This issue links to "upstream XStream PR 106 (Web Link)" [ 19899 ] |
Labels | Original: robustness xstream | New: diagnostics robustness xstream |
Resolution | New: Fixed [ 1 ] | |
Status | Original: In Review [ 10005 ] | New: Resolved [ 5 ] |
Labels | Original: diagnostics robustness xstream | New: diagnostics lts-candidate robustness xstream |
Link | New: This issue relates to JENKINS-49169 [ JENKINS-49169 ] |
Labels | Original: diagnostics lts-candidate robustness xstream | New: 2.89.4-rejected diagnostics lts-candidate robustness xstream |