Frequent SIGSEGV in Couchbase Lite Swift 4.1.0 during replication insertion (`HeapValue::release`)

[muruganandham-kuppan]

Describe the bug

We are seeing a frequent native crash with Couchbase Lite Swift 4.1.0 on iOS/iPadOS.

The crash occurs on a Couchbase Lite background thread while the replicator is processing and inserting an incoming revision.

The crashed stack is inside LiteCore/Fleece and eventually terminates at:

fleece::impl::internal::HeapValue::release(...)

with a SIGSEGV / SEGV_ACCERR.

There is no application-level code in the crashed thread.

This looks somewhat similar to #3499, which also involved native crashes inside Fleece/LiteCore. However, #3499 was reported against an earlier Couchbase Lite version and was mentioned as fixed in 4.1.0.

We are already using 4.1.0, and this crash occurs through a different path related to replication insertion:

litecore::repl::Inserter
    ↓
CollectionImpl::putDocument
    ↓
VectorDocument::putExistingRevision
    ↓
VectorDocument::save
    ↓
VectorRecord::encodeBodyAndExtra
    ↓
DeDuplicateEncoder::writeValue
    ↓
Fleece HeapDict / ValueSlot
    ↓
HeapValue::release
    ↓
SIGSEGV

The crash occurs frequently in real-world usage but we have not yet been able to reproduce it deterministically in our development environment.

---

To Reproduce

We do not currently have a deterministic unit test or standalone sample project that reproduces the issue.

The crash is observed during normal replication activity.

General flow:

1. Open a Couchbase Lite database.
2. Configure collections used for synchronization.
3. Start Couchbase Lite replication.
4. Allow the replicator to continuously receive document revisions from Sync Gateway.
5. During processing of an incoming revision, Couchbase Lite occasionally crashes inside LiteCore/Fleece.

The relevant part of the crash stack is:

0  CouchbaseLiteSwift
   fleece::impl::internal::HeapValue::release(...)

1  CouchbaseLiteSwift
   fleece::impl::ValueSlot::setStringOrData(...)

2  CouchbaseLiteSwift
   fleece::impl::internal::HeapDict::kvArray()

3  CouchbaseLiteSwift
   fleece::impl::Array::impl::impl(...)

4  CouchbaseLiteSwift
   fleece::impl::DictIterator::DictIterator(...)

5  CouchbaseLiteSwift
   litecore::DeDuplicateEncoder::writeValue(...)

6  CouchbaseLiteSwift
   litecore::VectorRecord::encodeBodyAndExtra(...)

7  CouchbaseLiteSwift
   litecore::VectorRecord::save(...)

8  CouchbaseLiteSwift
   litecore::VectorDocument::save(...)

9  CouchbaseLiteSwift
   litecore::VectorDocument::_saveIfRequested(...)

10 CouchbaseLiteSwift
   litecore::VectorDocument::putExistingRevision(...)

11 CouchbaseLiteSwift
   litecore::CollectionImpl::putDocument(...)

12 CouchbaseLiteSwift
   litecore::repl::Inserter::insertRevisionNow(...)

13 CouchbaseLiteSwift
   litecore::repl::Inserter::_insertRevisionsNow(...)

14 CouchbaseLiteSwift
   litecore::actor::GCDMailbox::safelyCall(...)

Exception:

Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR

We are currently trying to identify whether a particular document structure, revision sequence, concurrency condition, or replication state consistently triggers the crash.

---

Expected behavior

The incoming revision should either:

• be successfully processed and stored by Couchbase Lite, or
• fail gracefully and report an error through the replication/database APIs.

A document/revision processing issue should not result in a native SIGSEGV inside LiteCore/Fleece.

---

Logs

We are collecting Couchbase Lite diagnostic logs with sensitive application and user information removed.

The crash itself occurs on the Couchbase Lite replication worker thread.

Relevant native stack:

fleece::impl::internal::HeapValue::release
fleece::impl::ValueSlot::setStringOrData
fleece::impl::internal::HeapDict::kvArray
fleece::impl::DictIterator::DictIterator
litecore::DeDuplicateEncoder::writeValue
litecore::VectorRecord::encodeBodyAndExtra
litecore::VectorRecord::save
litecore::VectorDocument::save
litecore::VectorDocument::putExistingRevision
litecore::CollectionImpl::putDocument
litecore::repl::Inserter::insertRevisionNow
litecore::repl::Inserter::_insertRevisionsNow
litecore::actor::GCDMailbox::safelyCall

A sanitized crash report can also be provided if required.

---

Screenshots

Not applicable.

The issue is a native runtime crash and does not have a specific UI state associated with it.

---

Platform (please complete the following information):

• Device: iPhone / iPad
• Architecture: ARM64
• OS: iOS / iPadOS 26.x
• Couchbase Version: CouchbaseLiteSwift 4.1.0
• Sync Gateway Version: 4.0.5-2.0.0
• Replication Type: Continuous replication

---

Additional context

Issue #3499 appears related because it also reported crashes inside Fleece/LiteCore.

In that issue, Couchbase identified a race between saving a document and freeing an internal database object. The maintainers later mentioned that the fix was included in Couchbase Lite 4.1.0.

We are already running 4.1.0, but are still seeing a frequent native crash inside Fleece/LiteCore.

There are two notable differences from #3499:

1. Couchbase Lite 4.0.2 crash in production after upgrade from 3.2.4 (Fleece Encoder::writeKey) #3499 primarily crashed around:

fleece::impl::Encoder::writeKey

Our crash occurs around:

fleece::impl::internal::HeapValue::release

2. Our stack indicates the crash is happening while processing an incoming revision through:

litecore::repl::Inserter::insertRevisionNow

rather than directly from an application-triggered Collection.save(document:) operation.

Could you please confirm:

• Whether this is a known issue in Couchbase Lite Swift 4.1.0 / LiteCore.
• Whether this could be another concurrency, ownership, or object-lifetime issue inside Fleece/LiteCore.
• Whether there are known scenarios involving replication and concurrent database access that could trigger this crash.
• Whether there is additional diagnostic logging that can identify the document/revision being processed immediately before Inserter::insertRevisionNow.
• Whether any workaround is recommended while this is being investigated.

crashlog.zip I've attached partial crash logs here.

[pasin]

This is not a known issue that we know of. How often is this issue? and Is this issue also found on the other CBL versions or just 4.1.0?

[jianminzhao]

"We can provide additional sanitized crash reports and Couchbase Lite logs if needed."
Yes, please. That would be very helpful.

[snej]

The bug in #3499 was a buffer overrun that wrote two bytes beyond a heap allocation, so its effects could be broader than just the crash reported therein. This looks a lot like it, in that the stack includes DeDuplicateEncoder which is the thing that called Encoder::snip() which was where the bug was.

[muruganandham-kuppan]

@pasin we recently updated the SDK version and ~60+ users are affected in last 72 hours. Crash count is around 200
User has to reinstall the app to proceed further.

@jianminzhao I've updated the description with the partial crash logs.