[SERVER-50838] Coverity analysis defect 115741: Unchecked return value Created: 09/Sep/20  Updated: 29/Oct/23  Resolved: 09/Nov/20

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

Type: Bug Priority: Major - P3
Reporter: Coverity Collector User Assignee: Eric Cox (Inactive)
Resolution: Fixed Votes: 0
Labels: coverity, coverity-pm-1854-tracking, qexec-team
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-51473 Check return value from SeekableRecor... Closed
Duplicate
is duplicated by SERVER-20050 uassert in IDHackStage if on failure ... Closed
Related
is related to SERVER-49363 Triage Coverity Issues for Query code... Closed
Backwards Compatibility: Minor Change
Operating System: ALL
Sprint: Query 2020-10-05, Query 2020-10-19, Query 2020-11-02, Query 2020-11-16
Participants:

 Description   

Unchecked return value

If the function returns an error value, the error value may be mistaken for a normal value. Value returned from a function is not checked for errors before being used
/src/mongo/db/exec/idhack.cpp:152: CHECKED_RETURN 115741 Calling "restore" without checking return value (as is done elsewhere 10 out of 20 times).



 Comments   
Comment by Githook User [ 09/Nov/20 ]

Author:

{'name': 'Eric Cox', 'email': 'eric.cox@mongodb.com', 'username': 'ericox'}

Message: SERVER-50838 Unchecked return value for recordCursor restore in IDHack stage
Branch: master
https://github.com/mongodb/mongo/commit/942649a9fd069a9feb4ed9cbec661a7136dd36a9

Comment by Eric Cox (Inactive) [ 09/Nov/20 ]

code review: https://mongodbcr.appspot.com/691110001/

Comment by Eric Cox (Inactive) [ 18/Sep/20 ]

Does this return false for the wiredtiger case?

https://github.com/mongodb/mongo/blob/master/src/mongo/db/storage/wiredtiger/wiredtiger_record_store.cpp#L685-L703

I think it uasserts or invariantStatusOK() in every path other than when it returns true. This could mean that we don't need to check the false case explicitly, correct?

Comment by James Wahlin [ 09/Sep/20 ]

We should explore whether it is OK to continue if _recordCursor->restore() returns false.

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