[SERVER-74530] Segfault in SBE's object destructor when passed an empty object Created: 02/Mar/23  Updated: 27/Oct/23  Resolved: 06/Mar/23

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

Type: Bug Priority: Major - P3
Reporter: Jennifer Peshansky (Inactive) Assignee: Jennifer Peshansky (Inactive)
Resolution: Gone away Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-49978 Support expression $dateFromString in... Closed
Operating System: ALL
Steps To Reproduce:

This can be reproduced by running mongod with SBE on and optimizations off:

./build/install/bin/mongod --setParameter featureFlagSbeFull=true --setParameter enableTestCommands=true --setParameter failpoint.disablePipelineOptimization="{mode:'alwaysOn'}"

and then in the mongo shell:

const coll = db.example;
coll.drop();
assert.commandWorked(coll.insert({_id: 0}));
 
let onError = {};
coll.aggregate(
                {$project: {date: {$dateFromString: {dateString: "invalid", onError: onError}}}});

Sprint: QE 2023-03-20
Participants:

 Description   

We are hitting a segmentation fault, because an already-destructed object is being destructed a second time.

Here is a stack trace of the first time the destructor is called:

#0  mongo::sbe::value::Object::~Object (this=0x55555b3e34a0)
    at src/mongo/db/exec/sbe/values/value.h:722
#1  0x00007ffff1027521 in mongo::sbe::value::releaseValueDeep (
    tag=<optimized out>, val=93825091384480)
    at src/mongo/db/exec/sbe/values/value.cpp:305
#2  0x00007ffff263368a in mongo::sbe::value::releaseValue (tag=-60,
    val=93825091384480) at src/mongo/db/exec/sbe/values/value.h:292
#3  mongo::sbe::vm::ByteCode::popAndReleaseStack (this=0x55555bd73d70)
    at src/mongo/db/exec/sbe/vm/vm.h:1483
#4  mongo::sbe::vm::ByteCode::runInternal (this=<optimized out>,
    code=0x55555b2b4600, position=<optimized out>)
    at src/mongo/db/exec/sbe/vm/vm.cpp:6842
#5  0x00007ffff261caaf in mongo::sbe::vm::ByteCode::runLambdaInternal (
    this=0x55555bd73d70, code=0x55555b3e34a0, position=93825091384480)
    at src/mongo/db/exec/sbe/vm/vm.cpp:5934
#6  0x00007ffff2632f9f in mongo::sbe::vm::ByteCode::runInternal (
    this=<optimized out>, this@entry=0x55555bd73d70,
    code=code@entry=0x55555b2b4600, position=<optimized out>, position@entry=0)
    at src/mongo/db/exec/sbe/vm/vm.cpp:6541
#7  0x00007ffff2636088 in mongo::sbe::vm::ByteCode::run (this=0x55555bd73d70,
    code=0x55555b2b4600) at src/mongo/db/exec/sbe/vm/vm.cpp:6958
#8  0x00007ffff27ee39b in mongo::sbe::ProjectStage::getNext (
    this=<optimized out>) at src/mongo/db/exec/sbe/stages/project.cpp:96
#9  0x00007ffff3ba0466 in mongo::fetchNextImpl<mongo::BSONObj> (
    root=0x55555bd73c80, resultSlot=0x5555561ec528, recordIdSlot=0x0,
    out=out@entry=0x7fffd91281c8, dlOut=dlOut@entry=0x0, returnOwnedBson=true)
    at src/mongo/db/query/plan_executor_sbe.cpp:537
#10 0x00007ffff3b9fefd in mongo::PlanExecutorSBE::getNextImpl<mongo::BSONObj> (
    this=this@entry=0x55555b4fe300, out=out@entry=0x7fffd91281c8,
    dlOut=dlOut@entry=0x0) at src/mongo/db/query/plan_executor_sbe.cpp:303
#11 0x00007ffff3b9e659 in mongo::PlanExecutorSBE::getNext (
    this=0x55555b4fe300, out=0x7fffd9128300, dlOut=0x0)
    at src/mongo/db/query/plan_executor_sbe.cpp:222

And the second time:

#0  mongo::sbe::value::Object::~Object (this=0x55555b3e34a0)
    at src/mongo/db/exec/sbe/values/value.h:722
#1  0x00007ffff1027521 in mongo::sbe::value::releaseValueDeep (
    tag=<optimized out>, val=93825091384480)
    at src/mongo/db/exec/sbe/values/value.cpp:305
#2  0x00007ffff263368a in mongo::sbe::value::releaseValue (tag=-60,
    val=93825091384480) at src/mongo/db/exec/sbe/values/value.h:292
#3  mongo::sbe::vm::ByteCode::popAndReleaseStack (this=0x55555bd73d70)
    at src/mongo/db/exec/sbe/vm/vm.h:1483
#4  mongo::sbe::vm::ByteCode::runInternal (this=<optimized out>,
    code=0x55555b2b4600, position=<optimized out>)
    at src/mongo/db/exec/sbe/vm/vm.cpp:6842
#5  0x00007ffff261caaf in mongo::sbe::vm::ByteCode::runLambdaInternal (
    this=0x55555bd73d70, code=0x55555b3e34a0, position=93825101921096)
    at src/mongo/db/exec/sbe/vm/vm.cpp:5934
#6  0x00007ffff2632f9f in mongo::sbe::vm::ByteCode::runInternal (
    this=<optimized out>, this@entry=0x55555bd73d70,
    code=code@entry=0x55555b2b4600, position=<optimized out>, position@entry=0)
    at src/mongo/db/exec/sbe/vm/vm.cpp:6541
#7  0x00007ffff2636088 in mongo::sbe::vm::ByteCode::run (this=0x55555bd73d70,
    code=0x55555b2b4600) at src/mongo/db/exec/sbe/vm/vm.cpp:6958
#8  0x00007ffff27ee39b in mongo::sbe::ProjectStage::getNext (
    this=<optimized out>) at src/mongo/db/exec/sbe/stages/project.cpp:96
#9  0x00007ffff3ba0466 in mongo::fetchNextImpl<mongo::BSONObj> (
    root=0x55555bd73c80, resultSlot=0x5555561ec528, recordIdSlot=0x0,
    out=out@entry=0x7fffd91281c8, dlOut=dlOut@entry=0x0, returnOwnedBson=true)
    at src/mongo/db/query/plan_executor_sbe.cpp:537
#10 0x00007ffff3b9fefd in mongo::PlanExecutorSBE::getNextImpl<mongo::BSONObj> (
    this=this@entry=0x55555b4fe300, out=out@entry=0x7fffd91281c8,
    dlOut=dlOut@entry=0x0) at src/mongo/db/query/plan_executor_sbe.cpp:303
#11 0x00007ffff3b9e659 in mongo::PlanExecutorSBE::getNext (
    this=0x55555b4fe300, out=0x7fffd9128300, dlOut=0x0)
    at src/mongo/db/query/plan_executor_sbe.cpp:222

The only visible difference between these two stack traces is in mongo::sbe::vm::ByteCode::runLambdaInternal: the position has increased.

Stepping through the code in GDB, it seems like the second destructor is being called immediately afterwards, and this happens right after builtInDateFromString returns onError.



 Comments   
Comment by Jennifer Peshansky (Inactive) [ 06/Mar/23 ]

This issue is not appearing in the current implementation of dateFromString now that onError is handled in the stage builder. It might come back if we try to return an empty object from the SBE VM for any other reason, but this is not currently the case.

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