[SERVER-17250] logOp rollback when legacy insert creates a namespace and then fails to insert the document (fatal assertion) Created: 11/Feb/15  Updated: 19/Sep/15  Resolved: 03/Mar/15

Status: Closed
Project: Core Server
Component/s: Write Ops
Affects Version/s: 3.0.0-rc8
Fix Version/s: 3.1.0

Type: Bug Priority: Critical - P2
Reporter: Kamran K. Assignee: Daniel Alabi
Resolution: Done Votes: 0
Labels: 28qa
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-15192 Make all logOp listeners rollback-safe Closed
Related
is related to SERVER-17265 thread convoys from WiredTigerRecover... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

db/instance.cpp, checkAndInsert() has this code:

877    WriteUnitOfWork wunit(txn);
878    Collection* collection = ctx.db()->getCollection( ns );
879    if ( !collection ) {
880        collection = ctx.db()->createCollection( txn, ns );
881        verify( collection );
882        repl::logOp(txn,
883                    "c",
884                    (ctx.db()->name() + ".$cmd").c_str(),
885                    BSON("create" << nsToCollectionSubstring(ns)));
886    }
887
888    StatusWith<RecordId> status = collection->insertDocument( txn, js, true );
889    uassertStatusOK( status.getStatus() );
890    repl::logOp(txn, "i", ns, js);
891    wunit.commit();

If the uassertStatusOK() call on 889 throws after creating a collection, then the server will abort with an fassert: 'Rollback of logOp not currently allowed'

Rollback of logOp not currently allowed (SERVER-15192)
Fatal Assertion 18805
 
#0  0x00007ffff7bcc20b in raise (sig=5) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:37
#1  0x00000000018d53ce in mongo::breakpoint () at src/mongo/util/debugger.cpp:63
#2  0x00000000018ca463 in mongo::fassertFailed (msgid=18805) at src/mongo/util/assert_util.cpp:165
#3  0x00000000015f6f54 in mongo::repl::RollbackPreventer::rollback (this=0x30cc428) at src/mongo/db/repl/oplog.cpp:389
#4  0x00000000017005b8 in mongo::DurRecoveryUnit::rollbackInnermostChanges (this=0x32ce340) at src/mongo/db/storage/mmap_v1/dur_recovery_unit.cpp:174
#5  0x00000000016ffcc6 in mongo::DurRecoveryUnit::endUnitOfWork (this=0x32ce340) at src/mongo/db/storage/mmap_v1/dur_recovery_unit.cpp:78
#6  0x0000000001141854 in mongo::WriteUnitOfWork::~WriteUnitOfWork (this=0x7ffff7fcc1a0, __in_chrg=<optimized out>) at src/mongo/db/operation_context.h:156
#7  0x000000000144d9a6 in mongo::checkAndInsert (txn=0x7ffff7fcc7d0, ctx=..., ns=0x4d82814 "test.logop_rollback", js=...) at src/mongo/db/instance.cpp:892
#8  0x000000000144eff3 in mongo::receivedInsert (txn=0x7ffff7fcc7d0, m=..., op=...) at src/mongo/db/instance.cpp:1078
#9  0x000000000144a341 in mongo::assembleResponse (txn=0x7ffff7fcc7d0, m=..., dbresponse=..., remote=..., fromDBDirectClient=false) at src/mongo/db/instance.cpp:460
#10 0x0000000001142274 in mongo::MyMessageHandler::process (this=0x30cc1c8, m=..., port=0x30f2580, le=0x34102d0) at src/mongo/db/db.cpp:206
#11 0x00000000018f34d4 in mongo::PortMessageServer::handleIncomingMsg (arg=0x30f2580) at src/mongo/util/net/message_server_port.cpp:229
#12 0x00007ffff7bc4182 in start_thread (arg=0x7ffff7fcd700) at pthread_create.c:312
#13 0x00007ffff6cc500d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111



 Comments   
Comment by Githook User [ 03/Mar/15 ]

Author:

{u'username': u'alabid', u'name': u'alabid', u'email': u'alabidan@gmail.com'}

Message: SERVER-17250 Verify logOp listeners are rollback-safe
Branch: master
https://github.com/mongodb/mongo/commit/65f0efbe658d288267bd9c1f9f2a77a22794aacd

Comment by Andy Schwerin [ 11/Feb/15 ]

I think we should finish making logOp rollback safe and backport that fix to 3.0.x, instead of trying to catch all of these.

Comment by Eric Milkie [ 11/Feb/15 ]

I found a few other places in the source where we call logOp() and then might throw an exception, before calling commit on the WUOW.
mr.cpp:443
mr.cpp:457

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