[CDV-1051] TCObjectPhysical.literalValueChanged() methods call
setPeerObject() with null, which will throw NPE Created: 13/Nov/08 Updated: 12/Feb/14
Resolved:
12/Feb/14
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Resolved
Community Development (Terracotta Server)
DSO:L1
2.7.1
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Bug
Alex Miller
Won't Fix
None
Not Specified
Issue Links:
Related
relates to
Severity:
Fix In Branch:
Terracotta
Target:
None
Priority:
Assignee:
Votes:
2 Major
Interfaces Team
0
Not Specified
Not Specified
CDV-948
Integer (and probably other literals)...
Open
3 Feature failure (but usable), workaround available
trunk
Pending
Description
We found this with FindBugs. TCObjectPhysical.literalValueChanged() and .setLiteralValue()
both explicitly call TCObjectImpl.setPeerObject() with a null value (in the case of receiving a
null value). setPeerObject() dereferences the pased value, so is guaranteed to throw an NPE in
this case. Either setPeerObject() should be expecting a null OR the TCObjectPhysical methods
should be doing something different OR they shouldn't ever get null either.
Comments
Comment by Saravanan Subbiah [ 13/Nov/08 ]
I think we always pass ObjectID.NULL_ID and never null as such to literalValueChanged().
Anycase we should either change literalValueChanged() and setLiteralValue() to not send null
or setPeerObject() to handle null.
Comment by Alex Miller [ 14/Nov/08 ]
The expectation of nulls down this code path may be affected by this other jira - if literal roots
are reassignable (to null), then I think it can happen.
Comment by Alex Miller [ 14/Nov/08 ]
At current code status, I think that it's not possible to receive nulls down this path, so this
potential NPE will never actually occur. I'm going to defer making this an assertion however
until someone decides CDV-948 and determines whether tc literal non-primitives and/or nonliteral roots can be mutated (presumably including mutated to null).
Generated at Fri Feb 05 03:28:14 PST 2016 using JIRA 6.2.4#6261sha1:4d2e6f6f26064845673c8e7ffe9b6b84b45a6e79.