[SERVER-24093] Coverity analysis defect 98983: Explicit null dereferenced Created: 08/May/16  Updated: 10/May/16  Resolved: 08/May/16

Status: Closed
Project: Core Server
Component/s: WiredTiger
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Coverity Collector User Assignee: Keith Bostic (Inactive)
Resolution: Done 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   

Dereference of an explicit null value

Defect 98983 (STATIC_C)
Checker FORWARD_NULL (subcategory deref_constant_null)
File: /src/third_party/wiredtiger/src/session/session_api.c
Function __wt_session_range_truncate
/src/third_party/wiredtiger/src/session/session_api.c, line: 976
Dereferencing null pointer "start".

    		ret = start->next(start);

File: /src/third_party/wiredtiger/src/session/session_api.c
Function __wt_session_range_truncate
/src/third_party/wiredtiger/src/session/session_api.c, line: 1045
Dereferencing null pointer "start".

    		WT_ERR(start->next(start));



 Comments   
Comment by Keith Bostic (Inactive) [ 10/May/16 ]

Thanks for the explanation, milkie, that's been my experience as well.

Feel free to dump any of these to me, I'm happy to do the triage (and set it to "ignore in the future" if necessary), but that gives me a chance to restructure the code to make the complaint go away.

Comment by Eric Milkie [ 10/May/16 ]

From what I can tell, Coverity doesn't handle goto's well when tracking dependencies. In the case here, it doesn't connect returning not 0 from the function call with "start cannot be null". There have been a bunch of these that I have been triaging to ignore. It's possible to refine the detector such that it understands what the WT macros are doing, but I don't currently have such expertise.

Comment by Keith Bostic (Inactive) [ 08/May/16 ]

milkie, I agree with you, I don't see a problem here, but I don't understand why Coverity flagged it, either.

Can we please talk this one over?

In general, I like to change code to avoid Coverity's false positives, both because I'd rather Coverity didn't ignore stuff, and, of course, so a future change doesn't surface the same complaint again.

Comment by Eric Milkie [ 08/May/16 ]

False alarm.

Generated at Thu Feb 08 04:05:21 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.