[SERVER-28061] Coverity analysis defect 100574: Dereference null return value Created: 21/Feb/17 Updated: 27/Oct/23 Resolved: 21/Feb/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Coverity Collector User | Assignee: | Tess Avitabile (Inactive) |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | coverity | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Operating System: | ALL |
| Participants: |
| Description |
|
Return value of function which returns null is dereferenced without checking Defect 100574 (STATIC_C)
|
| Comments |
| Comment by Tess Avitabile (Inactive) [ 21/Feb/17 ] |
|
Thank you! |
| Comment by Eric Milkie [ 21/Feb/17 ] |
|
I took care of it, but in the Coverity interface you can change the Triage info on the right hand side and click Apply. |
| Comment by Tess Avitabile (Inactive) [ 21/Feb/17 ] |
|
Closing as Works As Designed. milkie, how do I mark this as a false positive in coverity? |
| Comment by Asya Kamsky [ 21/Feb/17 ] |
|
The issue is that Coverity does not know that when it takes false path at {{if (!orPushdownDescendants.empty()) }} then the loop that iterates over orPushdownDescendants will never be entered. This is the type of false positive that's beyond the type of tracking it can do. But a trivial way to fix this would be to include the for loop starting on line 284 inside the if-then along with the invariant. Alternatively just resolve it as WAD in Jira and mark it FP in Coverity. |
| Comment by David Storch [ 21/Feb/17 ] |
|
tess.avitabile, I think you can just resolve this ticket as Works as Designed. I can't recall if we have to do any other bookkeeping for the coverity issue, but milkie might know. |
| Comment by Tess Avitabile (Inactive) [ 21/Feb/17 ] |
|
We invariant that the return value is non-null in the cases where it will be dereferenced here, here, and here. Is there a way to tell coverity that this is not a defect? |