VBucket::abort (vb:156) - active failed as HashTable value is not CommittedState::Pending
Description
Components
Affects versions
Fix versions
Environment
Link to Log File, atop/blg, CBCollectInfo, Core dump
Release Notes Description
Attachments
relates to
Activity
Ashwin Govindarajulu May 27, 2021 at 6:47 PM
Not seeing this issue in latest weekly runs. Closing the ticket.
Dave Rigby February 5, 2021 at 3:08 PM
Given this hasn't been seen since August and a number of fixed have gone into HashTable state tracking, resolving as "Cannot Reproduce".
If this re-occurs please re-open and we can investigate further.
James Harrison January 18, 2021 at 4:46 PM
The provided pcap zips are rather small, and appear to contain just a pcaps directory
The logs from 2020-08-20 are very similar to previous presentations - clean node creates active vbucket and later an abort fails as the expected prepare was not found in the hashtable. Nothing suspicious logged, no restarts, no re-warmups, no vb takeovers.
One mild difference:
The committed value found in the hashtable was committed by prepare, rather than by mutation this time.
Going by the test log,
the document has been stored previously, then a subsequent update received a durability ambiguous response, before the attempted sync delete lead to the crash.
This is from some time ago, and a lot has changed since. Is this still reproducible?
Ashwin Govindarajulu August 20, 2020 at 8:34 AM
reproduced the same issue using 7.0.0-2241.
Please find the pcaps + cbcollect logs,
[^collectinfo-2020-08-20T073015-ns_1@10.112.191.102.zip]
[^collectinfo-2020-08-20T072825-ns_1@10.112.191.101.zip]
Ashwin Govindarajulu August 6, 2020 at 7:07 AM
Update:
Tried reproducing using the same build and not able to reproduce the same crash on server VMs. But seeing a new issue .
Will update the ticket after few more retries.
Build: 7.0.0-2241
Scenario:
Two node cluster, Couchbase bucket (replicas=1)
Performing durability abort scenario tests using sigstop on memcached process on each node
Observation:
Followed by the crash, the docs in the server are not accessible.
Cb_collect_logs:
https://cb-jira.s3.us-east-2.amazonaws.com/logs/mc_crash/collectinfo-2020-06-04T105726-ns_1%4010.112.191.103.zip
https://cb-jira.s3.us-east-2.amazonaws.com/logs/mc_crash/collectinfo-2020-06-04T105726-ns_1%4010.112.191.104.zip
Testcase: