[SERVER-7006] mongo tools seg fault in 2.2.0 with replica sets in connection string Created: 11/Sep/12 Updated: 11/Jul/16 Resolved: 14/Sep/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Tools |
| Affects Version/s: | 2.2.0 |
| Fix Version/s: | 2.2.3, 2.3.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Joonas Reynders | Assignee: | siddharth.singh@10gen.com |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Linux Mint 12, CentOS 6.2 |
||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||
| Description |
|
Mongoimport started core dumping with replica sets when we upgraded to 2.2.0. I can reproduce it with a local three node replica set. When importing directly to PRIMARY everything works: mongoimport -h localhost -d test -c my_collection test.json but if the set is added to the host string then mongoimport core dumps: mongoimport -h foo/localhost -d test -c my_collection test.json from foo/ It does not matter what kind of json document is imported, the one shown here is trivial: cat test.json I tried the exact same setup with Mongo 2.0.7 and everything works perfectly: mongoimport -h foo/localhost -d test -c my_collection test.json from foo/ |
| Comments |
| Comment by siddharth.singh@10gen.com [ 19/Sep/12 ] |
|
https://github.com/mongodb/mongo/commit/2b48ac27f5feae6c2bdf0ec53912870a8e2ee3e9 |
| Comment by siddharth.singh@10gen.com [ 14/Sep/12 ] |
|
https://github.com/mongodb/mongo/commit/ca91de625f1b565f38621635f595326b70d30f37 |
| Comment by Ian Whalen (Inactive) [ 13/Sep/12 ] |
|
as mentioned in the linked tickets, this problem affects all of the tools. |
| Comment by Tad Marshall [ 12/Sep/12 ] |
|
The crash is apparently caused by static destructors running in a non-deterministic order at program exit. So, it's ugly and shouldn't happen, but the main code logic has already exited before this happens. |
| Comment by aleksey [ 11/Sep/12 ] |
|
I believe, this is duplicate of |