[
https://issues.apache.org/jira/browse/CASSANDRA-7000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13963638#comment-13963638
]
Ben Chan commented on CASSANDRA-7000:
-------------------------------------
It was against 5ebadc1, but applies cleanly against the current trunk (ccef061
as of this moment). I'm getting a problem with ccef061 with a failure at {{ccm
start}}, but here is an (admittedly simple) before/after test for e1e91be:
{noformat}
W=https://issues.apache.org/jira/secure/attachment
for url in \
$W/12639219/sstablereader-assertion.patch \
$W/12639294/sstablereader-assertion-bisect-helper-v2
do [ -e $(basename $url) ] || curl -sO $url; done &&
chmod +x sstablereader-assertion-bisect-helper-v2
git checkout e1e91be
# sanity check downloaded scripts as always
./sstablereader-assertion-bisect-helper-v2 && echo ok
# should fail "before" and work "after"
git apply sstablereader-assertion.patch &&
./sstablereader-assertion-bisect-helper-v2 && echo ok
{noformat}
(You can ignore all the errors due to patches that don't apply; I needed to fix
a build problem in order to successfully run the bisect.)
> Assertion in SSTableReader during repair.
> -----------------------------------------
>
> Key: CASSANDRA-7000
> URL: https://issues.apache.org/jira/browse/CASSANDRA-7000
> Project: Cassandra
> Issue Type: Bug
> Reporter: Ben Chan
> Assignee: Ben Chan
> Attachments: sstablereader-assertion-bisect-helper,
> sstablereader-assertion-bisect-helper-v2, sstablereader-assertion.patch
>
>
> I ran a {{git bisect run}} using the attached bisect script. Repro code:
> {noformat}
> # 5dfe241: trunk as of my git bisect run
> # 345772d: empirically determined "good" commit.
> git bisect start 5dfe241 345772d
> git bisect run ./sstablereader-assertion-bisect-helper-v2
> {noformat}
> The first failing commit is 5ebadc1 (first parent of {{refs/bisect/bad}}).
> Prior to 5ebadc1, SSTableReader#close() never checked reference count. After
> 5ebadc1, there was an assertion for {{references.get() == 0}}. However, since
> the reference count is initialized to 1, a SSTableReader#close() was always
> guaranteed to either throw an AssertionError or to be a second call to
> SSTableReader#tidy() on the same SSTableReader.
> The attached patch chooses an in-between behavior. It requires the reference
> count to match the initialization value of 1 for SSTableReader#close(), and
> the same behavior as 5ebadc1 otherwise.
> This allows repair to finish successfully, but I'm not 100% certain what the
> desired behavior is for SSTableReader#close(). Should it close without regard
> to reference count, as it did pre-5ebadc1?
> Edit: accidentally uploaded a flawed version of
> {{sstablereader-assertion-bisect-helper}} (doesn't work out-of-the-box with
> {{git bisect}}).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
