[SERVER-14435] Mongodump gives Segmentation Fault Created: 03/Jul/14  Updated: 07/Apr/23  Resolved: 21/Jul/14

Status: Closed
Project: Core Server
Component/s: Querying, Tools
Affects Version/s: 2.6.3
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Fredrik Wallenius Assignee: Matt Kangas
Resolution: Cannot Reproduce Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to TOOLS-725 ISODate FailedToParse in tools query ... Closed
Operating System: ALL
Sprint: Server 2.7.4
Participants:

 Description   

I am trying to run mongodump with a timestamp based query. The objects stored in the collection have one property called "date" as below:

        "date" : ISODate("2014-04-03T02:12:19.753Z")

When running this on the command line:

$ mongodump -d mydb -o /data/s3backup/dump/ -q "{'date': {\$lte: new Date(1404388463000) }}" -c myColl

..I get the following output:

connected to: 10.0.1.251
2014-07-03T12:17:13.240+0000 DATABASE: mydb   to     /data/s3backup/dump/mydb
2014-07-03T12:17:13.243+0000    mydb.myColl to /data/s3backup/dump/mydb/myColl.bson
Segmentation fault (core dumped)

Versions
MongoDB Shell + Server: 2.6.3
OS: CentOS release 6.5 (Final)



 Comments   
Comment by Matt Kangas [ 21/Jul/14 ]

Closing per reporter's request

Comment by Fredrik Wallenius [ 19/Jul/14 ]

Sorry about that.

Feel free to close it. This is no longer an issue for us and I haven't found the time to debug it further. Thanks a lot for your support.

Comment by Ramon Fernandez Marina [ 18/Jul/14 ]

fredrik.wallenius, we haven't heard back from you for some time. If this is still an issue for you, can you please provide the information Matt requested above?

Thanks,
Ramón.

Comment by Matt Kangas [ 04/Jul/14 ]

Hi fredrik.wallenius,

If a permissions issue results in a segmentation fault, I agree that a better error message would be helpful. But I tried to repro using the directions you provided and I see a different result. Can you please provide one of the following?

  • A minimal set of directions to reproduce the segmentation fault, or
  • A stacktrace from mongodump, which you can obtain using gdb

Here is what I see when I try to reproduce your results on OS X using v2.6.3

$ ~/versions/mongodb-osx-x86_64-2.6.3/bin/mongodump -o tmp -d mydb -q "{'date': {\$lte: new Date(1404388463000) }}" -c myColl
connected to: 127.0.0.1
2014-07-04T12:08:58.034-0400 DATABASE: mydb	 to 	tmp/mydb
2014-07-04T12:08:58.035-0400 	mydb.myColl to tmp/mydb/myColl.bson
assertion: 10262 couldn't open file: errno:13 Permission denied
 
$ mongo mydb
MongoDB shell version: 2.6.1
connecting to: mydb
> db.myColl.find()
{ "_id" : ObjectId("53b6d03bf4a89a4f2ad2c9bc"), "date" : ISODate("2014-04-03T02:12:19.753Z") }
>
bye
 
$ ls -ld tmp/mydb
drwxr-xr-x  2 root  nobody  68 Jul  4 12:04 tmp/mydb/
 
$ ~/versions/mongodb-osx-x86_64-2.6.3/bin/mongodump --version
 version 2.6.3

When the target "mydb" directory is removed, I see this:

$ ~/versions/mongodb-osx-x86_64-2.6.3/bin/mongodump -o tmp -d mydb -q "{'date': {\$lte: new Date(1404388463000) }}" -c myColl
connected to: 127.0.0.1
2014-07-04T12:20:14.479-0400 DATABASE: mydb	 to 	tmp/mydb
error: boost::filesystem::create_directory: Permission denied: "tmp/mydb"

Comment by Fredrik Wallenius [ 04/Jul/14 ]

Embarrassing. I forgot to sudo. Didn't have write permissions on the output folder.
Still, a better error message would be nice to have for confused people like me

Thanks!

Comment by Thomas Rueckstiess [ 03/Jul/14 ]

Hi Fredrik,

Your query argument on date looks correct, you can see this approach works in the linked ticket SERVER-12390 (in the comments), and I also confirmed it on a small test dataset.

Did you confirm that the destination was available/mounted when you ran the dump?

To investigate the seg fault, can you please attach the mongod log file of the server you connected to, covering the entire period of the mongodump?

Thanks,
Thomas

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