VBucket::abort (vb:156) - active failed as HashTable value is not CommittedState::Pending

Description

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:

Components

Affects versions

Fix versions

None

Environment

Enterprise Edition 7.0.0 build 2241 Centos7 on Vagrant box

Link to Log File, atop/blg, CBCollectInfo, Core dump

None

Release Notes Description

None

Attachments

7

Activity

Show:

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.

Cannot Reproduce
Pinned fields
Click on the next to a field label to start pinning.

Details

Assignee

Ashwin Govindarajulu

Reporter

Is this a Regression?

Unknown

Triage

Triaged

Operating System

Centos 64-bit

Story Points

1

Priority

Instabug

Open Instabug

PagerDuty

Sentry

Zendesk Support

Created June 4, 2020 at 11:14 AM
Updated May 27, 2021 at 6:47 PM
Resolved February 5, 2021 at 3:08 PM
Instabug
Loading...