[SERVER-11363] Update call causes mongod to crash Created: 24/Oct/13  Updated: 10/Dec/14  Resolved: 13/Nov/13

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

Type: Bug Priority: Major - P3
Reporter: Amalia Hawkins Assignee: Scott Hernandez (Inactive)
Resolution: Duplicate Votes: 0
Labels: 26qa
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-4830 Reject upsert if would create duplica... Closed
Related
related to SERVER-6835 Sharding edge case upserts documents ... Closed
Operating System: ALL
Steps To Reproduce:

From SERVER-6835:

use test
db.repro.update({"_id.shardKey": 1, "_id": {shardKey: 1, uniquifier: 1}}, { $setOnInsert: { payload: 1 }}, { upsert: true })

Participants:

 Description   

Attempting to repro the scenario reported in SERVER-6835 led to the realization that the behavior has deteriorated. Instead of creating a document with 2 _id fields, the command now crashes the mongod.

The command:

db.repro.update({"_id.shardKey": 1, "_id": {shardKey: 1, uniquifier: 1}}, { $setOnInsert: { payload: 1 }}, { upsert: true })

Stack trace:

#0  0x00000001002ff2d7 in mongo::pathsupport::findLongestPrefix (root={_doc = 0x104aa5c78, _repIdx = 0}, prefix=@0x104aa5960, idxFound=0x104aa5960, elemFound=0x104aa5960)
    at path_support.cpp:152
#1  0x000000010031124f in mongo::Status::code () at /Users/Amalia/mongo/src/mongo/base/status-inl.h:184
#2  0x000000010031124f in mongo::UpdateDriver::createFromQuery (query=@0x104aa59a0, doc=@0x104aa5c78) at update_driver.cpp:186
#3  0x000000010030d0b0 in mongo::Status::isOK () at update.cpp:461
#4  0x000000010030d0b0 in mongo::Status::code () at /Users/Amalia/mongo/src/mongo/base/status-inl.h:215
#5  0x000000010030d0b0 in mongo::UpdateRequest::getQuery () at /Users/Amalia/mongo/src/mongo/db/ops/update_request.h:41
#6  0x000000010030d0b0 in mongo::update (request=@0x104aa61a0, opDebug=0x104aa61a0, driver=0x104aa61a0) at update.cpp:461
#7  0x00000001002912ba in mongo::receivedUpdate (m=@0x104aa65e0, op=@0x104aa65e0) at instance.cpp:678
#8  0x00000001002954ba in mongo::assembleResponse (m=@0x104aa61e8, dbresponse=@0x104aa6b60, remote=@0x5) at instance.cpp:486
#9  0x0000000100007144 in mongo::MyMessageHandler::process (this=0x104aa61e8, m=@0x104aa6c70, port=0x104aa6c70, le=0x104aa6c70) at db.cpp:199
#10 0x00000001005da701 in boost::shared_ptr<mongo::Socket>::operator-> () at /Users/Amalia/mongo/src/third_party/boost/boost/smart_ptr/shared_ptr.hpp:209
#11 0x00000001005da701 in mongo::PortMessageServer::handleIncomingMsg (arg=0x104aa61e8) at message_server_port.cpp:210
#12 0x00000001006420b5 in thread_proxy (param=0x1043ef600) at thread.cpp:121
#13 0x00007fff907858bf in _pthread_start ()
#14 0x00007fff90788b75 in thread_start ()



 Comments   
Comment by Andrew Morrow (Inactive) [ 24/Oct/13 ]

scotthernandez

I'm not sure its a dup. Different stack trace. I think the problem here is that it is not legal to pass NULL as the last parameter to findLongestPrefix as UpdateDriver::createFromQuery does. I think elemFound should be initialized to doc.end();

Comment by Scott Hernandez (Inactive) [ 24/Oct/13 ]

dup of SERVER-4830

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