couchbase / moss / 103 / 1
83%
master: 83%

DEFAULT BRANCH: master
Ran
Files 19
Run time 2s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 85.599%. Remained the same
103.1

push

travis-ci

steveyen 
MB-20899 - only mmapRefresh an old footer when it's in active use

mossStore tracks a linked-list of previous footers, where each footer
struct has its own ref-count.

When a new mmap'ed []byte is available due to a latest-&-greatest
footer being written/appended to the mossStore file, we can run
through that linked-list of previous footers and "refresh" them, which
means we can decrement the ref-count on the previous, old mmap'ed
[]byte for an old footer and increment the ref-count on the latest
mmap'ed []byte.

BUT, on the decrement of the ref-count, if it hits zero, the old
mmap'ed []byte is unmap()'ed -- which means that any access of that
memory immediately leads to a segfault (hence, MB-20899).

So, this fix performs this mmap'ed []byte refreshing for previous
footers only if a previous footer's ref-count is > 1.

For example, an application might have an old snapshot (1 ref-count)
and an iterator on that snapshot (a 2nd ref-count), and might be
likely to create even more iterators from that old snapshot.  Since
the ref-count is 2, a mmap'ed []byte refresh won't lead to an unmap().

If the application just has a snapshot only (just 1 ref-count on the
mmap'ed []byte) on the previous footer, then we don't touch it,
favoring correctness over a crash, at the cost of temporarily using
more mmap'ed resources.

Change-Id: I7a2d0b6db
Reviewed-on: http://review.couchbase.org/67651
Reviewed-by: Marty Schoch <marty.schoch@gmail.com>
Tested-by: Steve Yen <steve.yen@gmail.com>

2015 of 2354 relevant lines covered (85.6%)

10892.3 hits per line

Source Files on job 103.1
Coverage ∆ File Lines Relevant Covered Missed Hits/Line