[SERVER-7632] jstests/drop2.js and jstests/killop.js failing (auth issue) Created: 12/Nov/12  Updated: 11/Jul/16  Resolved: 16/Nov/12

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

Type: Bug Priority: Major - P3
Reporter: Spencer Brody (Inactive) Assignee: Spencer Brody (Inactive)
Resolution: Done Votes: 0
Labels: buildbot
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File testOutput.txt     Text File testOutput_sm.txt    
Issue Links:
Duplicate
is duplicated by SERVER-7637 Fix jstests/drop2.js when run with auth Closed
is duplicated by SERVER-7682 drop2.js failing on 64-bit Legacy mac... Closed
Related
is related to SERVER-2407 Switch to v8 Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:

 Description   

jstests/drop2.js fails consistently on my local machine when built with the now-default v8. My machine is Ubuntu Linux, doing a 64 bit debug build. Weirdly, this test doesn't seem to be failing on buildbot, though it fails for me every time. If I compile mongod with --usesm, the test passes.

I have attached the output of running the test twice, once with mongod compiled using default flags, and once with mongod compiled using --usesm.



 Comments   
Comment by auto [ 16/Nov/12 ]

Author:

{u'date': u'2012-11-16T22:54:23Z', u'email': u'spencer@10gen.com', u'name': u'Spencer T Brody'}

Message: Don't query admin.system.users when initializing AuthorizationManager if we aren't running with auth SERVER-7632
Branch: master
https://github.com/mongodb/mongo/commit/5bbf1c926dc40db801572871e0a9d8f167f2e859

Comment by Eric Milkie [ 16/Nov/12 ]

Thanks for that investigation. Spencer's going to fix the new auth code to respect the --noauth command line parameter.

Comment by Aaron Staple [ 16/Nov/12 ]

I think this is why the drop2.js test is failing, sequence of events:

1) The test issues a count, which acquires a read lock and does a loop forever inside javascript. The read lock is not released.
2) The dur thread attempts to acquire a write lock and is not able to do so because count has a read lock.
3) The client issues a drop. Before the drop command is run, the authorization manager is initialized, which checks if there is a privileged document using AuthorizationManager::hasPrivilegedDocument()
4) The implementation of AuthorizationManager::hasPrivilegedDocument() does a find using dbdirectclient. The dbdirectclient (temporarily) replaces the curop information for the drop command with its own curop information.
5) The dbdirectclient find cannot acquire a read lock because there is a pending write lock (from the dur thread).
6) The test looks for the drop command in curop, but it cannot be found because AuthorizationManager::hasPrivilegedDocument()'s use of a dbdirectclient find replaced the curop information and the find cannot proceed because it cannot acquire a read lock.
7) The test eventually times out.

Not really sure who should work to fix this. Reassigning back to you for now.

Comment by Eric Milkie [ 16/Nov/12 ]

Hey Aaron.
jstests/killop.js is failing due to the same problem.
I can force the test to fail every time if I put a sleep in between the two startParalellShell queries. They are both using the same count({$where}) function that drop2.js is using.

Comment by Eric Milkie [ 16/Nov/12 ]

Hi Aaron, I'm bumping this to you.
I can get drop2.js to fail consistently if I just insert a sleep(1000) at line 33.
This test fails even with --usesm (SpiderMonkey). I believe the problem might be that count() is now holding a different series of locks, which prevents the drop() from beginning? Could it be that the changes to count() have affected this?

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