[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: File core.34722.gz     File core.36392.gz    
Issue Links:
Related
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

  • If I switch the deletions to be executed 1 by 1 (no parallelism), the crash doesn't occur anymore.
  • The crash occurs with mongod 5.0.14 and 6.0.4. If I downgrade to 4.4.18, the crash doesn't occur anymore. 

----------------

I was able to generate 2 core dumps (in attachment) with mongod 6.0.4:

  • One sees the segfault in ephemeral_for_test::RadixStore<...>::merge3
  • The other in  mongo::ephemeral_for_test::CursorBase::setEndPosition


 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 (DOCS-15887) to make sure we update our documentation.

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 SERVER-65151).

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 ]

Hi luc.vidal@360learning.com,

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,
Yuan

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