[SERVER-18201] disk/repair5.js fails intermittently Created: 24/Apr/15  Updated: 19/Sep/15  Resolved: 28/Apr/15

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

Type: Bug Priority: Critical - P2
Reporter: Spencer Brody (Inactive) Assignee: Kaloian Manassiev
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Backwards Compatibility: Fully Compatible
Operating System: ALL
Participants:
Linked BF Score: 0

 Description   

54c25da33e Windows 64-bit disk

Test failure

logs

test history

2015-04-23T22:54:28.877+0000 E QUERY    Error: command worked when it should have failed: { "ok" : 1 } : undefined
    at Error (<anonymous>)
    at doassert (src/mongo/shell/assert.js:11:14)
    at Function.assert.commandFailed (src/mongo/shell/assert.js:262:5)
    at C:\data\mci\shell\src\jstests\disk\repair5.js:43:8 at src/mongo/shell/assert.js:13
failed to load: C:\data\mci\shell\src\jstests\disk\repair5.js



 Comments   
Comment by Githook User [ 24/Apr/15 ]

Author:

{u'username': u'stbrody', u'name': u'Spencer T Brody', u'email': u'spencer@mongodb.com'}

Message: SERVER-18201 Make sure js code is the last argument to mongo shell in startParallelShell
Branch: master
https://github.com/mongodb/mongo/commit/9ad121c1653c73b73a099e5efd26953859734483

Comment by Githook User [ 24/Apr/15 ]

Author:

{u'username': u'kaloianm', u'name': u'Kaloian Manassiev', u'email': u'kaloian.manassiev@mongodb.com'}

Message: SERVER-18201 Fix a missed variable declaration

This fails the test, because it is declared to 'use strict'
Branch: master
https://github.com/mongodb/mongo/commit/9cf89ce4f44f3885e5bea05c31d5a40cd86c4b4c

Comment by Githook User [ 24/Apr/15 ]

Author:

{u'username': u'kaloianm', u'name': u'Kaloian Manassiev', u'email': u'kaloian.manassiev@mongodb.com'}

Message: SERVER-18201 Explicitly pass the port to the test shell

While at it, I also put the test into a function so it doesn't change
global variables.
Branch: master
https://github.com/mongodb/mongo/commit/4370f71f9f79799a273682bf61548c8f2694f964

Comment by Kaloian Manassiev [ 24/Apr/15 ]

Looks like this is related to commit 8b7528029686ca1ae0eec681169406d52eb27682, which is causing the test shell to go against the wrong mongod instance.

Comment by Spencer Brody (Inactive) [ 24/Apr/15 ]

Both this and BF-872 involve waiting for something to show up in currentOp() and not finding it. I suspect they may have the same root cause, something to do with currentOp().

Comment by Spencer Brody (Inactive) [ 24/Apr/15 ]

Huh, almost looks like the command may be returning success before actually doing its work?

	
2015-04-23T22:54:28.877+0000 E QUERY    Error: command worked when it should have failed: { "ok" : 1 } : undefined
    at Error (<anonymous>)
    at doassert (src/mongo/shell/assert.js:11:14)
    at Function.assert.commandFailed (src/mongo/shell/assert.js:262:5)
    at C:\data\mci\shell\src\jstests\disk\repair5.js:43:8 at src/mongo/shell/assert.js:13
failed to load: C:\data\mci\shell\src\jstests\disk\repair5.js
 m27000| 2015-04-23T22:54:21.672+0000 I COMMAND  [conn1] repairDatabase jstests_disk_repair5
 m27000| 2015-04-23T22:54:21.676+0000 I STORAGE  [conn1] repairDatabase jstests_disk_repair5
 m27000| 2015-04-23T22:54:22.070+0000 I JOURNAL  [conn1] journalCleanup...
 m27000| 2015-04-23T22:54:22.070+0000 I JOURNAL  [conn1] removeJournalFiles
 m27000| 2015-04-23T22:54:22.071+0000 I INDEX    [conn1] allocating new ns file C:\data\db/jstests_disk_repair5/repairDir/backup_repairDatabase_0\jstests_disk_repair5.ns, filling with zeroes...
 m27000| 2015-04-23T22:54:22.117+0000 I STORAGE  [FileAllocator] allocating new datafile C:\data\db/jstests_disk_repair5/repairDir/backup_repairDatabase_0\jstests_disk_repair5.0, filling with zeroes...
 m27000| 2015-04-23T22:54:22.117+0000 I STORAGE  [FileAllocator] creating directory C:\data\db/jstests_disk_repair5/repairDir/backup_repairDatabase_0\_tmp
sh5824| 2015-04-23T22:54:35.185+0000 I NETWORK  DBClientCursor::init call() failed
 m27000| 2015-04-23T22:54:22.373+0000 I STORAGE  [FileAllocator] done allocating datafile C:\data\db/jstests_disk_repair5/repairDir/backup_repairDatabase_0\jstests_disk_repair5.0, size: 64MB,  took 0.255 secs
 m27000| 2015-04-23T22:54:22.383+0000 I INDEX    [conn1] build index on: jstests_disk_repair5.jstests_disk_repair5 properties: { v: 1, key: { _id: 1 }, name: "_id_", ns: "jstests_disk_repair5.jstests_disk_repair5" }
 m27000| 2015-04-23T22:54:22.383+0000 I INDEX    [conn1] 	 building index using bulk method
 m27000| 2015-04-23T22:54:22.495+0000 I STORAGE  [FileAllocator] allocating new datafile C:\data\db/jstests_disk_repair5/repairDir/backup_repairDatabase_0\jstests_disk_repair5.1, filling with zeroes...
 m27000| 2015-04-23T22:54:23.074+0000 I STORAGE  [FileAllocator] done allocating datafile C:\data\db/jstests_disk_repair5/repairDir/backup_repairDatabase_0\jstests_disk_repair5.1, size: 128MB,  took 0.578 secs
 m27000| 2015-04-23T22:54:23.917+0000 I JOURNAL  [conn1] journalCleanup...
 m27000| 2015-04-23T22:54:23.919+0000 I JOURNAL  [conn1] removeJournalFiles
 m27000| 2015-04-23T22:54:23.951+0000 I JOURNAL  [conn1] journalCleanup...
 m27000| 2015-04-23T22:54:23.951+0000 I JOURNAL  [conn1] removeJournalFiles
 m27000| 2015-04-23T22:54:24.066+0000 I JOURNAL  [conn1] journalCleanup...
 m27000| 2015-04-23T22:54:24.066+0000 I JOURNAL  [conn1] removeJournalFiles
 m27000| 2015-04-23T22:54:24.105+0000 I INDEX    [conn1] restarting 0 background index build(s)
 m27000| 2015-04-23T22:54:24.105+0000 I COMMAND  [conn1] command jstests_disk_repair5.$cmd command: repairDatabase { repairDatabase: 1.0, backupOriginalFiles: true } ntoskip:0 keyUpdates:0 writeConflicts:0 numYields:0 reslen:37 locks:{ Global: { acquireCount: { W: 1 } }, MMAPV1Journal: { acquireCount: { w: 40014 }, acquireWaitCount: { w: 3 }, timeAcquiringMicros: { w: 66903 } }, Metadata: { acquireCount: { W: 15 } } } 2433ms

though you can't really trust the order of log messages displayed across processes in buildlogger, so may also be a red herring.

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