[SERVER-4129] server segfault when starting with a wrong replSet name Created: 24/Oct/11  Updated: 11/Jul/16  Resolved: 21/Dec/11

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: 2.0.1
Fix Version/s: 2.1.0

Type: Bug Priority: Critical - P2
Reporter: Malte Finsterwalder Assignee: Eric Milkie
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

debian linux 64bit


Attachments: File mongodump.log    
Issue Links:
Duplicate
is duplicated by SERVER-5806 Mongo Segfaults When Assigning Elasti... Closed
Operating System: Linux
Participants:

 Description   

I was running a culster named "cluster_green" with 5 servers (4 main servers and one arbiter).
I deleted all the databases (rm on disk) on the four main servers, but left the 5th server (the arbiter) unchanged.
I then configured the four main servers to use a different replSet called "green".
When I restarted the arbiter, configured to replSet "green", the server crashed.
(see attached log file)



 Comments   
Comment by Eric Milkie [ 21/Dec/11 ]

The call stack indicates an access of a global variable that needs mutex protection. I added a mutex so it should no longer crash; this will be present in version 2.1.0.

Comment by auto [ 20/Dec/11 ]

Author:

{u'login': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}

Message: SERVER-4129 fix race condition on global by adding mutex protection

This global variable is accessed by multiple threads (via multiple connections); one thread
can write to the std::set while another is reading, and bad things happen. Helgrind threw fits
for this one until I patched things over by making this code change.
Branch: master
https://github.com/mongodb/mongo/commit/8de99aae6b84dee5a09481e2b50da518456522bd

Comment by Kristina Chodorow (Inactive) [ 29/Nov/11 ]

I am unable to reproduce, but I think you ran into a threading bug with seed discovery. Working on it...

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