[SERVER-42987] If an abortTransaction command gets interrupted we may dereference a null pointer inside abortActiveUnpreparedOrStashPreparedTransaction Created: 22/Aug/19 Updated: 29/Oct/23 Resolved: 11/Sep/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 4.2.0, 4.3.1 |
| Fix Version/s: | 4.3.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | William Schultz (Inactive) | Assignee: | Judah Schvimer |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||
| Backport Requested: |
v4.2
|
||||||||||||||||||||
| Sprint: | Repl 2019-08-26, Repl 2019-09-09, Repl 2019-09-23 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
When we run a command via 'invokeWithSessionCheckedOut' we register an exit guard here which will fire if the command throws an uncaught exception. If we are running an 'abortTransaction' command on a session that currently has a prepared transaction, it is possible that the command gets interrupted. For example, if a concurrent killOp command has killed the operation. There is at least one interruption point within the 'abortTransaction' command where we try to log an abort oplog entry and then update the session entry. We try to acquire a lock there via AutoGetCollection. If the abort command throws after we have already cleaned up the OperationContext resources, then the WriteUnitOfWork on the opCtx will have been set to null. So, if we then try to stash our transaction resources inside 'TransactionParticipant::Participant::_stashActiveTransaction' when the exit guard fires, we may dereference the null WUOW. |
| Comments |
| Comment by Githook User [ 11/Oct/19 ] |
|
Author: {'name': 'Judah Schvimer', 'username': 'judahschvimer', 'email': 'judah.schvimer@10gen.com'}Message: (cherry picked from commit 1659ddcfb49050dcf18fef014cd9d5ebf5717650) |
| Comment by Githook User [ 11/Sep/19 ] |
|
Author: {'username': 'judahschvimer', 'email': 'judah.schvimer@10gen.com', 'name': 'Judah Schvimer'}Message: |
| Comment by William Schultz (Inactive) [ 23/Aug/19 ] |
|
I believe commitPreparedTransaction is immune to this issue because we log the oplog entry inside an uninterruptible block. |