[SERVER-7790] Segfault in splitchunk following dropDatabase Created: 28/Nov/12  Updated: 10/Dec/14  Resolved: 02/May/14

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

Type: Bug Priority: Major - P3
Reporter: Mathias Stearn Assignee: Unassigned
Resolution: Duplicate Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVER-13410 split does not install metadata under... Closed
Related
is related to SERVER-10012 Segmentation fault on splitChunk Closed
Operating System: ALL
Participants:

 Description   

Wed Nov 28 16:40:24 [conn50988] splitChunk accepted at version 4|1||50b63e70340d76a5cd58c72b
Wed Nov 28 16:40:25 [conn50988] about to log metadata event: { _id: "mongodb-4a-2012-11-28T16:40:25-1779", server: "mongodb-4a", clientAddr: "10.250.81.21:46454", time: new Date(1354120825021), what: "split", ns: "XXXX", details: { before: { min: { _id: "c0" }, max: { _id: MaxKey }, lastmod: Timestamp 1000|6, lastmodEpoch: ObjectId('000000000000000000000000') }, left: { min: { _id: "c0" }, max: { _id: "||" }, lastmod: Timestamp 4000|2, lastmodEpoch: ObjectId('50b63e70340d76a5cd58c72b') }, right: { min: { _id: "||" }, max: { _id: MaxKey }, lastmod: Timestamp 4000|3, lastmodEpoch: ObjectId('50b63e70340d76a5cd58c72b') } } }
Wed Nov 28 16:40:25 Invalid access at address: 0xbc from thread: conn50988
Wed Nov 28 16:40:25 Got signal: 11 (Segmentation fault).
Wed Nov 28 16:40:25 Backtrace:
0xaf8c41 0x5586c9 0x558c52 0x7f26c2364cb0 0xa403fc 0x6e8321 0x6e9b92 0x6eab4c 0x830028 0x83376b 0x7b0b0d 0x7b20e2 0x56fe42 0xae6ed1 0x7f26c235ce9a 0x7f26c166fcbd 
/usr/bin/mongod(_ZN5mongo15printStackTraceERSo+0x21) [0xaf8c41]
/usr/bin/mongod(_ZN5mongo10abruptQuitEi+0x399) [0x5586c9]
/usr/bin/mongod(_ZN5mongo24abruptQuitWithAddrSignalEiP7siginfoPv+0x262) [0x558c52]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xfcb0) [0x7f26c2364cb0]
/usr/bin/mongod(_ZN5mongo17SplitChunkCommand3runERKSsRNS_7BSONObjEiRSsRNS_14BSONObjBuilderEb+0x7f9c) [0xa403fc]
/usr/bin/mongod(_ZN5mongo12_execCommandEPNS_7CommandERKSsRNS_7BSONObjEiRNS_14BSONObjBuilderEb+0x51) [0x6e8321]
/usr/bin/mongod(_ZN5mongo11execCommandEPNS_7CommandERNS_6ClientEiPKcRNS_7BSONObjERNS_14BSONObjBuilderEb+0xd52) [0x6e9b92]
/usr/bin/mongod(_ZN5mongo12_runCommandsEPKcRNS_7BSONObjERNS_11_BufBuilderINS_16TrivialAllocatorEEERNS_14BSONObjBuilderEbi+0x2ac) [0x6eab4c]
/usr/bin/mongod(_ZN5mongo11runCommandsEPKcRNS_7BSONObjERNS_5CurOpERNS_11_BufBuilderINS_16TrivialAllocatorEEERNS_14BSONObjBuilderEbi+0x38) [0x830028]
/usr/bin/mongod(ZN5mongo8runQueryERNS_7MessageERNS_12QueryMessageERNS_5CurOpES1+0xc0b) [0x83376b]
/usr/bin/mongod() [0x7b0b0d]
/usr/bin/mongod(_ZN5mongo16assembleResponseERNS_7MessageERNS_10DbResponseERKNS_11HostAndPortE+0x3a2) [0x7b20e2]
/usr/bin/mongod(_ZN5mongo16MyMessageHandler7processERNS_7MessageEPNS_21AbstractMessagingPortEPNS_9LastErrorE+0x82) [0x56fe42]
/usr/bin/mongod(_ZN5mongo3pms9threadRunEPNS_13MessagingPortE+0x411) [0xae6ed1]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x7f26c235ce9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f26c166fcbd]



 Comments   
Comment by Greg Studer [ 02/May/14 ]

Pretty sure this is a duplicate of the issue we found while testing 2.6.0.

Comment by Scott Hernandez (Inactive) [ 08/Aug/13 ]

This is most likely a test environment issue. It might happen in production if there are frequent drops for databases with balancing sharded collections.

In a productions deployment, with replica sets, this would cause a failover to another replica or a mongos instance failure. This would decrease the availability of the sharded cluster temporarily but only slightly, and would automatically recover after the failure or node restart.

Mathias, can you provide a reproduction of the issue for further investigation?

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