-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 3.6.1
-
Component/s: Sharding
-
Environment:docker container mongo:3.6.1 (debian jessy)
https://github.com/docker-library/mongo/blob/657b1a53a9680b972a6344f3d958a17775dd8719/3.6/Dockerfile
-
Fully Compatible
-
ALL
-
-
Sharding 2018-02-12, Sharding 2018-02-26, Sharding 2018-03-12, Sharding 2018-03-26, Sharding 2018-04-23
-
(copied to CRM)
The starting point are 3 node: 2 data barer and 1 arbitrer. All nodes started without the flag --shardsvr. Once the replicaset is initialized (initialization + addArb) it cannot be converted to a replicated shard.
Once you restart the node with the flag --shardsvr they, after a while, access a bad memory segment (Invalid access at address: 0x18) and receive signal SIGSEGV.
If restarted again they continue to receive the same signal after some time in idle (more or less 5 minute)
- causes
-
SERVER-33376 MongoDB 3.6.3-rc0 config server segfaults on startup
- Closed
-
SERVER-34746 Segmentation fault when shard is started with --shardsvr before being added to a shard
- Closed
- depends on
-
SERVER-29908 Libraries db/s/sharding and db/query/query are directly cyclic
- Closed
- is depended on by
-
TOOLS-2011 Restore sharded cluster testing after SERVER-32677
- Closed
- is duplicated by
-
SERVER-32921 Invalid access at address: 0x18
- Closed
-
SERVER-33385 MongoDB 3.6 crashes on Ubuntu 16.04 AWS when using Cold SC1 EBS Volume
- Closed
-
SERVER-34206 All replica nodes crash
- Closed
-
SERVER-34530 Shard server crashes after access violation on Windows v3.7.4-6-g228106a741
- Closed
- related to
-
SERVER-71106 Access to Grid members should be protected with isShardingInitialized
- Closed