[SERVER-5680] repl13.js failing on Windows 64-bit Created: 21/Apr/12 Updated: 11/Jul/16 Resolved: 01/May/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 2.0.7, 2.1.1 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Ian Whalen (Inactive) | Assignee: | Eric Milkie |
| Resolution: | Done | Votes: | 0 |
| Labels: | Windows, buildbot | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
http://buildbot.mongodb.org/builders/Windows%2064-bit/builds/4658/steps/test_10/logs/stdio |
||
| Issue Links: |
|
||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||
| Operating System: | Windows | ||||||||||||||||
| Participants: | |||||||||||||||||
| Description |
|
http://buildbot.mongodb.org/builders/Windows%2064-bit/builds/4658/steps/test_10/logs/stdio |
| Comments |
| Comment by auto [ 27/Jul/12 ] | |||
|
Author: {u'date': u'2012-04-30T10:42:02-07:00', u'email': u'milkie@10gen.com', u'name': u'Eric Milkie'}Message: Conflicts: | |||
| Comment by Eric Milkie [ 30/Apr/12 ] | |||
|
Note that this should fix the test failures from the slow weekly builders as well. I looked at their dump files and rollback4.js is crashing in the same place (rec->touch()). | |||
| Comment by auto [ 30/Apr/12 ] | |||
|
Author: {u'login': u'milkie', u'name': u'Eric Milkie', u'email': u'milkie@10gen.com'}Message: | |||
| Comment by Eric Milkie [ 30/Apr/12 ] | |||
|
Running in debug mode, repl13.js hits an assert on startup:
| |||
| Comment by Eric Milkie [ 30/Apr/12 ] | |||
|
Unfortunately, this test failed again with the same access violation, even after Andy's change was introduced. It's odd to me how it's this one particular test that keeps hitting an accvio, on the same line of code. I'm going to attempt to flush it out running in the debugger. | |||
| Comment by Tad Marshall [ 26/Apr/12 ] | |||
|
This should be fixed by by Andy's addition of LockMongoFilesExclusive to remapPrivateView in Windows. Memory accesses to the private view being remapped would generate access violations if they happened during the window of time between the unmap and remap operations. | |||
| Comment by auto [ 25/Apr/12 ] | |||
|
Author: {u'login': u'andy10gen', u'name': u'Andy Schwerin', u'email': u'schwerin@10gen.com'}Message: LockMongoFilesExclusive in remapViewOfFiles on Windows. Since remapViewOfFiles isn't atomic on Windows, it must exclusively acquire the See | |||
| Comment by Tad Marshall [ 23/Apr/12 ] | |||
|
I tried to find the faulting code (hard because ASLR gives you 254 possible locations and we haven't added any code to allow us to adjust for this) and found one solid candidate: NamespaceDetailsTransient::notifyOfWriteOp() at line 537 in db/namespace_details.h. /* you must notify the cache if you are doing writes, as query plan utility will change */ I tried running the test on my home machine and was not able to duplicate the crash. It is possible that this is a compiler bug, broken in the original Visual Studio 2010 run by the Buildbot but fixed in the Service Pack 1 version running on my machine, but that is a guess and probably wishful thinking. | |||
| Comment by Tad Marshall [ 21/Apr/12 ] | |||
|
This seems relevant: m31000| Sat Apr 21 02:23:13 [conn2] *** unhandled exception (access violation) at 0x000000013FD52EFE, terminating |