Crash when accessing `connection->name()`

Thread 1 name:

Thread 1 Crashed:

0   CouchbaseLiteSwift             	 0x000000010b8e7ba4 litecore::repl::Worker::Worker(litecore::blip::Connection*, litecore::repl::Worker*, litecore::repl::Options const&, std::__1::shared_ptr<litecore::repl::DBAccess>, char const*) (string:1515)

1   CouchbaseLiteSwift             	 0x000000010b8e7dd4 litecore::repl::Worker::Worker(litecore::repl::Worker*, char const*) (memory:0)

2   CouchbaseLiteSwift             	 0x000000010b891b00 litecore::repl::IncomingRev::IncomingRev(litecore::repl::Puller*) (IncomingRev.cc:39)

3   CouchbaseLiteSwift             	 0x000000010b8d4d1c litecore::repl::Puller::startIncomingRev(litecore::blip::MessageIn*) (RefCounted.hh:108)

4   CouchbaseLiteSwift             	 0x000000010b8d5a8c litecore::repl::Puller::_revWasProvisionallyHandled() (Puller.cc:275)

5   CouchbaseLiteSwift             	 0x000000010b968578 litecore::actor::GCDMailbox::safelyCall(void () block_pointer) const (GCDMailbox.cc:91)

6   CouchbaseLiteSwift             	 0x000000010b96864c invocation function for block in litecore::actor::GCDMailbox::enqueue(void () block_pointer) (GCDMailbox.cc:102)

7   libdispatch.dylib              	 0x00000001beb92610 _dispatch_call_block_and_release (libdispatch.dylib)

8   libdispatch.dylib              	 0x00000001beb93184 _dispatch_client_callout (libdispatch.dylib)

9   libdispatch.dylib              	 0x00000001beb70710 _dispatch_lane_serial_drain$VARIANT$armv81 (libdispatch.dylib)

10  libdispatch.dylib              	 0x00000001beb71128 _dispatch_lane_invoke$VARIANT$armv81 (libdispatch.dylib)

11  libdispatch.dylib              	 0x00000001beb7a43c _dispatch_workloop_worker_thread (libdispatch.dylib)

12  libsystem_pthread.dylib        	 0x00000001bebe2b88 _pthread_wqthread (libsystem_pthread.dylib)

13  libsystem_pthread.dylib        	 0x00000001bebe5760 start_wqthread (libsystem_pthread.dylib)

Jens Alfke added a comment - 10/Feb/20 3:47 PM

Yes, it looks like the Worker constructor is operating on a bogus std::string (or char*). The only string operation going on is 

string(namePrefix) + connection->name() ... namePrefix is hardcoded to "inc" in the IncomingRev constructor. BLIPConnection::name() just returns a string member variable. Weird.

Jens Alfke added a comment - 19/Feb/20 2:38 PM

From code inspection, the only thing I can think could cause this is if the Puller's `_connectionClosed()` method had previously been called. Then its `_connection` member would be null, and so null would be passed for the`blip::Connection*` parameter of the Worker constructor in frame 1. This would cause the constructor's call to `connection->name()` to return a reference to a `std::string` object at a near-zero address, and the string concatenation at Worker.cc:86 would crash reading the string.

This seems feasible. At the time of the crash the Puller is handing its actor/async method `_revWasProvisionallyHandled`, which is initiated by `Inserter::_insertRevisionsNow`. So the connection may have closed unexpectedly, triggering an async `_connectionClosed` call, while simultaneously the Inserter is working on revisions and calls `_revWasProvisionallyHandled` an instant later.