[SERVER-81018] Access violation error Created: 13/Sep/23 Updated: 29/Dec/23 Resolved: 29/Dec/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 5.0.19, 5.0.20, 5.0.21 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Fabian Eisinger | Assignee: | Alison Rhea Thorne |
| Resolution: | Gone away | Votes: | 0 |
| Labels: | windows-10 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
Windows 10 Enterprise 12H2 |
||
| Attachments: |
|
| Operating System: | ALL |
| Steps To Reproduce: | I'm unable to reproduce this error in a mvp |
| Participants: |
| Description |
|
When running integration tests in a NodeJs project that integrates with mongoDB via mongoose I receive a timeout error after a short while because the mongoDB database that has been started with mongodb-memory-server crashed after an access violation error. It occurs with all v5 Versions of mongoDB and is fixed with v6. Versions
package: mongo-memory-server What is the Problem? Testcases time out after 2000ms. The debug output of memory-server shows
(full log below) Mongod is started in mochaGlobalSetup with:
The error occurs consistently but not always in the same testmethod. But it can be traced back to a particular line in the code under test, which is:
Commenting this code snippet resolves the error. Also executing it in series resolves this error with:
Setting the option `writeConcern` to `1` also resolves the error but leads to other issues. As soon as `writeConcern` is `2, 3 or majority` the error occurs again. `task.countingScope` is right now an array of length 3. Reducing it to length 2 also solves the issue. Executing the tests agains a local cluster started with `run-rs` of the same version also resolves the error. The only thing even close to the error I've found is https://github.com/Automattic/mongoose/issues/5376. An issue from 2017 and for mongoose v4 which recommends setting `useMongoClient`, an option which is the default by now. Debug Output The file startup_debug.txt shows the debug output of mongodb-memory-server on startup |
| Comments |
| Comment by Alison Rhea Thorne [ 29/Dec/23 ] |
|
Hi @Fabian, Thank you for the clarification. The ephemeralForTest engine was only intended for testing purposes, and has since been deprecated and removed in more recent versions of MongoDB (as you observed). With that in mind, I'm going to go ahead and close this ticket. |
| Comment by Fabian Eisinger [ 11/Dec/23 ] |
|
Hello rhea.thorne@mongodb.com No I'm still not able to provide a MVP or similar. The error started happening after I added 5 new testcases. I tried added them one by one but couldn't figure out which testcase caused the issue because the error didn't happen. This explains why the error never occured when using my local MongoDB Cluster and only with MongoDBMemoryServer. |
| Comment by Alison Rhea Thorne [ 04/Dec/23 ] |
|
We still need additional information to diagnose the problem. If this is still an issue for you, could you answer the following:
|
| Comment by Alison Rhea Thorne [ 13/Nov/23 ] |
|
Hello Fabian, Thank you for providing the logfiles and diagnostics as requested. Unfortunately, the FTDC that was collected doesn't contain enough data to be actionable in and of itself (likely due to the time period in which the mongod instance was running, as it is running during tests specifically). That said, I do have a few questions:
Thank you, |
| Comment by Fabian Eisinger [ 24/Oct/23 ] |
|
rhea.thorne@mongodb.com I managed to get the log files from the mongo instances and uploaded everything you requested as "mongod-logs-full.zip". Let me know if you need a higher log level. It should be easier for me now to achieve it. hasezoey@gmail.com Thank you for putting me on the right path. That's exactly what I did and with a few hacky patches to MMS I got the logfiles |
| Comment by hasezoey N/A [ 17/Oct/23 ] |
|
> When adding --logpath <path> to the node cli options they wouldn't start and be terminated after 20s.
using `–logpath` changes the log output instead of duplicating the log to the logpath (log output to stdout gets disabled), from my quick investigation `systemLog`(in the config file) does the same thing. if this option was added as a argument to creating a instance with mongodb-memory-server (via `replSet.args`), then this is to be expected because MMS relies on the stdout log to be able to parse the mongod server state (though the default launch timeout is 10 seconds). if this was not the case, what actually do you mean with "node cli options"? (MMS does not provide a runnable binary and i dont think there is a binary in the mongodb node driver) |
| Comment by Alison Rhea Thorne [ 17/Oct/23 ] |
|
Hello Fabian. Thank you for uploading the diagnostic data, in regards to your question: yes the --logpath command line switch is the correct one to use. However, you may also use the configuration file to accomplish this. Heres a link to our doc on this: |
| Comment by Fabian Eisinger [ 11/Oct/23 ] |
|
rhea.thorne@mongodb.com I uploaded the diagnostic.data for each node as well as the log output from MongoDBMemoryServer again. |
| Comment by Alison Rhea Thorne [ 06/Oct/23 ] |
|
Thank you for your report! I've created a secure upload portal for you. Files uploaded to this portal are hosted on Box, are visible only to MongoDB employees, and are routinely deleted after some time. For each node in the replica set spanning a time period that includes the incident, would you please archive (tar or zip) and upload to that link:
|