-
Type:
Improvement
-
Resolution: Duplicate
-
Priority:
Minor - P4
-
None
-
Affects Version/s: 2.6.0
-
Component/s: Aggregation Framework
-
None
-
None
-
None
-
None
-
None
-
None
-
None
-
None
When running an aggregate command, it's possible to run into the 64MB limit defined in BufBuilder. It results in the following in the server log:
2014-04-14T18:12:40.526+0100 [conn336] Assertion: 13548:BufBuilder attempted to grow() to 134217728 bytes, past the 64MB limit.
2014-04-14T18:12:40.533+0100 [conn336] 0x11bd301 0x115f819 0x11441f6 0x76980d 0xc568ee 0xcf3b02 0xcf3b87 0xc5681e 0xca61bb 0xca6c10 0xc93a1b 0xc93de9 0xceb01c 0x9a9046 0xa1cfda 0xa1e04e 0xa1f806 0xd4c6a7 0xb96382 0xb98962
mongod(_ZN5mongo15printStackTraceERSo+0x21) [0x11bd301]
mongod(_ZN5mongo10logContextEPKc+0x159) [0x115f819]
mongod(_ZN5mongo11msgassertedEiPKc+0xe6) [0x11441f6]
mongod(_ZN5mongo11_BufBuilderINS_16TrivialAllocatorEE15grow_reallocateEi+0xed) [0x76980d]
mongod(_ZNK5mongo8Document18serializeForSorterERNS_11_BufBuilderINS_16TrivialAllocatorEEE+0x22e) [0xc568ee]
mongod(_ZNK5mongo5Value18serializeForSorterERNS_11_BufBuilderINS_16TrivialAllocatorEEE+0x492) [0xcf3b02]
mongod(_ZNK5mongo5Value18serializeForSorterERNS_11_BufBuilderINS_16TrivialAllocatorEEE+0x517) [0xcf3b87]
mongod(_ZNK5mongo8Document18serializeForSorterERNS_11_BufBuilderINS_16TrivialAllocatorEEE+0x15e) [0xc5681e]
mongod(_ZN5mongo6sorter13NoLimitSorterINS_5ValueENS_8DocumentENS_18DocumentSourceSort10ComparatorEE5spillEv+0x20b) [0xca61bb]
mongod(_ZN5mongo6sorter13NoLimitSorterINS_5ValueENS_8DocumentENS_18DocumentSourceSort10ComparatorEE3addERKS2_RKS3_+0x160) [0xca6c10]
mongod(_ZN5mongo18DocumentSourceSort8populateEv+0x17b) [0xc93a1b]
mongod(_ZN5mongo18DocumentSourceSort7getNextEv+0xb9) [0xc93de9]
mongod(_ZN5mongo8Pipeline3runERNS_14BSONObjBuilderE+0x13c) [0xceb01c]
mongod(_ZN5mongo15PipelineCommand3runERKSsRNS_7BSONObjEiRSsRNS_14BSONObjBuilderEb+0x526) [0x9a9046]
mongod(_ZN5mongo12_execCommandEPNS_7CommandERKSsRNS_7BSONObjEiRSsRNS_14BSONObjBuilderEb+0x3a) [0xa1cfda]
mongod(_ZN5mongo7Command11execCommandEPS0_RNS_6ClientEiPKcRNS_7BSONObjERNS_14BSONObjBuilderEb+0xd5e) [0xa1e04e]
mongod(_ZN5mongo12_runCommandsEPKcRNS_7BSONObjERNS_11_BufBuilderINS_16TrivialAllocatorEEERNS_14BSONObjBuilderEbi+0x6c6) [0xa1f806]
mongod(_ZN5mongo11newRunQueryERNS_7MessageERNS_12QueryMessageERNS_5CurOpES1_+0x2307) [0xd4c6a7]
mongod [0xb96382]
mongod(_ZN5mongo16assembleResponseERNS_7MessageERNS_10DbResponseERKNS_11HostAndPortE+0x442) [0xb98962]
2014-04-14T18:12:40.691+0100 [conn336] command stp.$cmd command: aggregate { $msg: "query not recording (too large)" } keyUpdates:0 numYields:242 locks(micros) r:4931103 reslen:142 17731ms
Since this is something that a user can encounter just by doing an innocent-looking $push, the server should not assert, and instead print a more meaningful log message (without the stack trace), and report an error from the command with a better clue as to the root cause of the problem.
- duplicates
-
-
- Backlog
-