[SERVER-11894] Inserting into a capped collection an object larger than max size causes a Signal 6 Abort Created: 28/Nov/13  Updated: 27/May/14  Resolved: 02/May/14

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

Type: Bug Priority: Major - P3
Reporter: James O'Leary Assignee: James O'Leary
Resolution: Cannot Reproduce Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

RHEL Version: 5.5


Issue Links:
Depends
Related
related to SERVER-8666 adding large docs to capped collectio... Closed
is related to SERVER-9551 Perform a minimum size validation whe... Closed
Operating System: Linux
Participants:

 Description   

As a work around in the short term, ensure that all capped collections are greater than the max BSON document size of 16MB.

Inserting a document greater than 0.5MB into a capped collection smaller that this size causes a Signal 6 Abort. See the following stack trace :

0xddd4a1 0xd9d1d3 0xc2647c 0xdaad21 0xe25c09 0x3c13e0673d 0x3c136d3f6d 
 /opt/ahl/releases/mongodb/2.4.6-1.ahl/bin/mongod(_ZN5mongo15printStackTraceERSo+0x21) [0xddd4a1]
 /opt/ahl/releases/mongodb/2.4.6-1.ahl/bin/mongod(_ZN5mongo13fassertFailedEi+0xa3) [0xd9d1d3]
 /opt/ahl/releases/mongodb/2.4.6-1.ahl/bin/mongod(_ZN5mongo7replset14multiSyncApplyERKSt6vectorINS_7BSONObjESaIS2_EEPNS0_8SyncTailE+0x12c) [0xc2647c]
 /opt/ahl/releases/mongodb/2.4.6-1.ahl/bin/mongod(_ZN5mongo10threadpool6Worker4loopEv+0x281) [0xdaad21]
 /opt/ahl/releases/mongodb/2.4.6-1.ahl/bin/mongod [0xe25c09]
 /lib64/libpthread.so.0 [0x3c13e0673d]
 /lib64/libc.so.6(clone+0x6d) [0x3c136d3f6d]
Thu Nov 28 10:29:37.715 [repl writer worker 1] 
 
***aborting after fassert() failure
 
 
Thu Nov 28 10:29:37.715 Got signal: 6 (Aborted).
 
Thu Nov 28 10:29:37.719 Backtrace:
0xddd4a1 0x6d0d29 0x3c136302d0 0x3c13630265 0x3c13631d10 0xd9d20e 0xc2647c 0xdaad21 0xe25c09 0x3c13e0673d 0x3c136d3f6d 
 /opt/ahl/releases/mongodb/2.4.6-1.ahl/bin/mongod(_ZN5mongo15printStackTraceERSo+0x21) [0xddd4a1]
 /opt/ahl/releases/mongodb/2.4.6-1.ahl/bin/mongod(_ZN5mongo10abruptQuitEi+0x399) [0x6d0d29]
 /lib64/libc.so.6 [0x3c136302d0]
 /lib64/libc.so.6(gsignal+0x35) [0x3c13630265]
 /lib64/libc.so.6(abort+0x110) [0x3c13631d10]
 /opt/ahl/releases/mongodb/2.4.6-1.ahl/bin/mongod(_ZN5mongo13fassertFailedEi+0xde) [0xd9d20e]
 /opt/ahl/releases/mongodb/2.4.6-1.ahl/bin/mongod(_ZN5mongo7replset14multiSyncApplyERKSt6vectorINS_7BSONObjESaIS2_EEPNS0_8SyncTailE+0x12c) [0xc2647c]
 /opt/ahl/releases/mongodb/2.4.6-1.ahl/bin/mongod(_ZN5mongo10threadpool6Worker4loopEv+0x281) [0xdaad21]
 /opt/ahl/releases/mongodb/2.4.6-1.ahl/bin/mongod [0xe25c09]
 /lib64/libpthread.so.0 [0x3c13e0673d]
 /lib64/libc.so.6(clone+0x6d) [0x3c136d3f6d]



 Comments   
Comment by James Blackburn [ 27/May/14 ]

No, only the log-files attached to the CS ticket where this was observed. It brought down the secondaries, but not the primary.

Comment by Thomas Rueckstiess [ 27/May/14 ]

Hi James,

we were unable to reproduce the problem as described and therefore closed the ticket. Do you have additional information or a script to reproduce the issue so we can investigate this further?

Thomas

Comment by James Blackburn [ 27/May/14 ]

Has this been fixed?

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