[SERVER-5967] unhandled exception: boost::filesystem::create_directory: Permission denied: "/data/shardA" Created: 31/May/12  Updated: 11/Jul/16  Resolved: 01/Jun/12

Status: Closed
Project: Core Server
Component/s: Testing Infrastructure
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: siddharth.singh@10gen.com Assignee: siddharth.singh@10gen.com
Resolution: Done Votes: 0
Labels: buildbot
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
is duplicated by SERVER-5969 "Permission denied" in drop_configdb.js Closed
Related
is related to SERVER-5842 Exceptions thrown in scripting/engine... Closed
Operating System: ALL
Participants:

 Description   

http://buildbot.mongodb.org/builders/Linux%2064-bit%20concurrency/builds/294/steps/test/logs/stdio



 Comments   
Comment by auto [ 31/May/12 ]

Author:

{u'login': u'singhsiddharth', u'name': u'Siddharth Singh', u'email': u'singhsiddharth@gmail.com'}

Message: SERVER-5967 Fixed the data directory for test
Branch: master
https://github.com/mongodb/mongo/commit/5abe8976e51bb2f1be6ae49015d31aa5e21c6ea4

Comment by Tad Marshall [ 31/May/12 ]

SpiderMonkey builds will no longer fassert on this error:

https://jira.mongodb.org/browse/SERVER-5842?focusedCommentId=124689&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-124689

The error is now returned to JavaScript the way it was before.

Comment by Tad Marshall [ 31/May/12 ]

Adding link to SpiderMonkey changes that made the SpiderMonkey build fassert instead of just failing the JavaScript function.

Comment by Tad Marshall [ 31/May/12 ]

The failure of the test "jstests/sharding/drop_config.js" happens in v8 as well, so that part isn't related to my change:

http://buildbot.mongodb.org/builders/Linux%2064-bit%20v8/builds/3498/steps/test_9/logs/stdio

But v8 just fails the JavaScript load, so the fassert from SpiderMonkey is wrong.

Comment by Tad Marshall [ 31/May/12 ]

The Fatal Assertion is coming from the new code I added. "native_helper" (on the stack backtrace) is used by the internal JavaScript native functions that are installed with calls to scope.injectNative() ... there are a whole bunch of them. We may need to add additional debugging output to identify the specific function that failed, though in this case the 'boost::filesystem::create_directory: Permission denied: "/data/shardA"' may be enough of a clue.

As written today, any exception that we haven't explicitly coded for will be consider "unhandled" by the JavaScript "native" code and will trigger a fatal assertion. So unless we change approaches, we need to have handlers for anything that is actually "expected".

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