Mongodump segmentation fault when dumping all dbs

Question

I'm running a mongodb(2.0.4) replicaset with one master and two slaves where one is hidden slave for backup. I'm using http://docs.mongodb.org/manual/core/replica-set-architecture-three-members/

When i run mongodump --oplog -h rsuat/10.0.3.163 --out /tmp/lala

I get :

Fri Dec 13 09:05:53 starting new replica set monitor for replica set rsuat with seed of 10.0.3.163
Fri Dec 13 09:05:53 successfully connected to seed 10.0.3.163 for replica set rsuat
Fri Dec 13 09:05:53 changing hosts to { 0: "10.0.2.234:27017", 1: "10.0.4.96:27017" } from rsuat/
Fri Dec 13 09:05:53 trying to add new host 10.0.2.234:27017 to replica set rsuat
Fri Dec 13 09:05:53 successfully connected to new host 10.0.2.234:27017 in replica set rsuat
Fri Dec 13 09:05:53 trying to add new host 10.0.4.96:27017 to replica set rsuat
Fri Dec 13 09:05:53 successfully connected to new host 10.0.4.96:27017 in replica set rsuat
Fri Dec 13 09:05:53 replica set monitor for replica set rsuat started, address is rsuat/10.0.2.234:27017,10.0.4.96:27017
Fri Dec 13 09:05:53 [ReplicaSetMonitorWatcher] starting
connected to: rsuat/10.0.3.163
all dbs
DATABASE: connect_log,mongodb:   to     /tmp/lala/connect_log,mongodb:
    connect_log,mongodb:.log to /tmp/lala/connect_log,mongodb:/log.bson
        131600/142621   92%
         142621 objects
    connect_log,mongodb:.system.indexes to /tmp/lala/connect_log,mongodb:/system.indexes.bson
         1 objects
Segmentation fault (core dumped)

It works without the oplog flag. Anyone got a clue what could be wrong?

EDIT: Segmentation fault seems to happen even if i dont use the oplog flag, so the error is when doing a full dump.

EDIT2: This is a line from syslog caused by the segault if that is of any help:

 ip-10-0-3-163 kernel: [23126212.267385] mongodump[26858]: segfault at 0 ip 00007f234ca776c4 sp 00007fff2b9d5f00 error 4 in libc-2.15.so[7f234ca09000+1b5000]

Answer 1

It should be noted that using --oplog does not constitute a "full dump", that flag dumps out any operations that were applied to the oplog between the start of the dump and the end of the dump. That is, it will give you a portion of the oplog so that your dump when restored (with --oplogReplay) will represent the data as it was at the end of the dump.

However, it does not dump the oplog itself, so if you are not inserting/updating during the dump, then it is not needed. In fact, I think there were a few empty collection bugs with mongodump so if there are no ops in the oplog between the start and finish of the dump then that might be your problem.

As another possible way to get around this - have you tried using newer versions of the tools (2.4.x etc.) against the 2.0.4 instance. Version 2.0.4 is pretty old at this point, there were even several more 2.0.x releases after it, not to mention 2 major releases with another due soon. You don't have to have a 2.4 version of the server to use its tools, that may get you around some of the older mongodump bugs.