Apple

The report of the offending address looks like this:

Address 0x7fff5fbfb7d8 is located in stack of thread T0 at offset 120 in frame

#0 0x1009c781f in fleece::Writer::output() const Writer.cc:113

This frame has 11 object(s):

[32, 40) 'retval.i.i41'

[64, 72) 'retval.i44'

[96, 97) 'ref.tmp.i.i'

[112, 113) '__annotator.i'

[128, 136) 'retval.i.i' <== Memory access at offset 120 underflows this variable

Assuming '__annotator.i' is an __RAII_IncreaseAnnotator object, the offending address is actually safely inside the object. The problem is that the sanitizer believes the object to be only one byte long (as shown in the stack frame log), whereas it's actually 16 bytes long. Suspiciously, the object would be empty if the preprocessor symbol '_LIBCPP_HAS_NO_ASAN' were defined, so it seems like ASAN is working with an inconsistent parse of the source.

—Jens

References:
	>False(?) positive from new Address Sanitizer C++ STL container check (From: Jens Alfke <email@hidden>)