[SERVER-73550] Segmentation fault: in mongo::ephemeral_for_test::RadixStore::_mergeResolveConflict Created: 02/Feb/23 Updated: 27/Feb/23 Resolved: 08/Feb/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | 5.0.14, 6.0.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Luc Vidal | Assignee: | Louis Williams |
| Resolution: | Won't Fix | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Attachments: |
|
||||
| Issue Links: |
|
||||
| Assigned Teams: |
Storage Execution
|
||||
| Operating System: | ALL | ||||
| Steps To Reproduce: | It's complicated to reproduce, because it depends on the list of impacted collections. |
||||
| Sprint: | Execution Team 2023-03-06 | ||||
| Participants: | |||||
| Description |
|
I'm working on a JS progam using MongoDB. Our integration tests use the npm library `mongo-memory-server` to download/run a mongod server with ephemeral_for_tests engine. Each test cleans its test collections by issuing `collection.deleteMany({})` on every modified collection during the test. All these deleteMany are executed in parallel. When executing many tests, it happens that the mongod server crashes with a segfault. Workarounds
---------------- I was able to generate 2 core dumps (in attachment) with mongod 6.0.4:
|
| Comments |
| Comment by Louis Williams [ 08/Feb/23 ] |
|
Thanks luc.vidal@360learning.com. I agree it would be a good idea to warn them about the breaking change coming in 7.0. I also filed a ticket ( |
| Comment by Luc Vidal [ 08/Feb/23 ] |
|
Hi Louis Williams, thank you so much for your detailed explanation. I'll ping the owner of npm library `mongo-memory-server` to warn them about this. From my point of view, you can close this issue.
|
| Comment by Louis Williams [ 07/Feb/23 ] |
|
Hi luc.vidal@360learning.com, I just want to elaborate on yuan.fang@mongodb.com's comment above: In 5.0, we replaced the ephemeralForTest storage engine implementation with a different one, codenamed "Biggie" internally. But it's still called ephemeralForTest for your purposes. The new implementation was much more sophisticated, but it proved very difficult to maintain. It had many bugs, like the one you discovered, and in the 7.0 release, we will remove the ephemeralForTest engine entirely (see What does that mean for you? Luckily, the default WiredTiger storage engine is very fast, and it also happens to have strong durability guarantees. So long as you're not constantly starting and stopping the database, WiredTiger should be a suitable alternative for your purposes. You can also mount the database to a tmpfs (Temporary File System), and startup/shutdown should be even faster. Let me know if this provides a suitable workaround. |
| Comment by Yuan Fang [ 07/Feb/23 ] |
|
Thank you for contacting us. Unfortunately, the support for the ephemeralForTest feature has reached its end of life in MongoDB. For this issue, we'd like to encourage you to start by asking our community for help by posting on the MongoDB Developer Community Forums. If the discussion there leads you to suspect a bug in the MongoDB server, then we'd want to investigate it as a possible bug here in the SERVER project. Additionally, in case you were not aware, the ephemeralForTest SE has been replaced by the BiggieSE starting from version 5.0. Regards, |