[MB-11835] Stack-corruption crash opening db, if path len > 250 bytes Created: 28/Jul/14  Updated: 28/Jul/14

Status: Open
Project: Couchbase Server
Component/s: forestdb
Affects Version/s: 2.5.1
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Critical
Reporter: Jens Alfke Assignee: Jung-Sang Ahn
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Triage: Untriaged
Is this a Regression?: Unknown

 Description   
If the path to a database file is more than 250 bytes long, and auto-compaction is enabled, the stack will be corrupted, probably causing a crash. The reason is that compactor_is_valid_mode() copies the path into a stack buffer 256 bytes long and then appends a 5-byte suffix to it.

The buffer needs to be bigger. I suggest using MAXPATHLEN as the size, at least on Unix systems; it's a common Unix constant defined in <sys/param.h>. On Apple platforms the value is 1024.

Backtrace of the crash in the iOS simulator looks like this; apparently __assert_rtn is an OS stack sanity check.

* thread #1: tid = 0x6112d, 0x0269969e libsystem_kernel.dylib`__pthread_kill + 10, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
    frame #0: 0x0269969e libsystem_kernel.dylib`__pthread_kill + 10
    frame #1: 0x0265e2c1 libsystem_pthread.dylib`pthread_kill + 101
    frame #2: 0x023a59c9 libsystem_sim_c.dylib`abort + 127
    frame #3: 0x0237053b libsystem_sim_c.dylib`__assert_rtn + 284
  * frame #4: 0x000b3644 HeadlessBee`compactor_is_valid_mode(filename=<unavailable>, config=<unavailable>) + 276 at compactor.cc:774
    frame #5: 0x000bafd9 HeadlessBee`_fdb_open(handle=<unavailable>, filename=<unavailable>, config=0xbfff8ee0) + 201 at forestdb.cc:842
    frame #6: 0x000baede HeadlessBee`fdb_open(ptr_handle=<unavailable>, filename=<unavailable>, fconfig=0xbfff9010) + 158 at forestdb.cc:528

The actual path causing the crash (251 bytes long) was:

/Volumes/Retina2/Users/snej/Library/Developer/CoreSimulator/Devices/F889372A-F7E8-4534-B6B3-C3E23EFE528C/data/Applications/988D316C-31F3-4A05-8EDC-79C86061C7C9/Library/Application Support/CouchbaseLite/test13_itunesindex-db.cblite2/x:artists.viewindex




[MB-11783] We need the administrator creds available in isasl.pw Created: 22/Jul/14  Updated: 22/Jul/14

Status: Open
Project: Couchbase Server
Component/s: ns_server
Affects Version/s: 3.0
Fix Version/s: None
Security Level: Public

Type: Improvement Priority: Major
Reporter: Trond Norbye Assignee: Aleksey Kondratenko
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   
We'd like to add authentication for some of the operations (like setting configuration tunables dynamically). Instead of telling the user to go look in on the system for isasl.pw and dig out the _admin entry and then use that and the generated password, it would be nice if the credentials defined when setting up the cluster could be used.

 Comments   
Comment by Aleksey Kondratenko [ 22/Jul/14 ]
Interesting. Very much :)

I cannot do it because we don't have administrator creds anymore. We just have some kind of password hash and that's it.

I admit my fault. I could be more forward looking. But it was somewhat guided by your response back in the day which I interpreted as reluctance to allow memcached auth via admin credentials.
Comment by Aleksey Kondratenko [ 22/Jul/14 ]
And of course all admin ops to memcached can still be safely and in more controlled way (global if needed, or local if needed) be handled by ns_server.




[MB-11780] [Upgrade tests] Before upgrade, after configuring XDCR on 2.0.0-1976, node become un-responsive Created: 22/Jul/14  Updated: 23/Jul/14

Status: Open
Project: Couchbase Server
Component/s: ns_server
Affects Version/s: 2.0
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Sangharsh Agarwal Assignee: Aleksey Kondratenko
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: Version: 2.0.0-1976-rel
Ubuntu 12.04

Triage: Untriaged
Operating System: Ubuntu 64-bit
Link to Log File, atop/blg, CBCollectInfo, Core dump: [Source]
10.3.3.218 : https://s3.amazonaws.com/bugdb/jira/MB-11780/2b77fbd0/10.3.3.218-diag.txt.gz
10.3.3.218 : https://s3.amazonaws.com/bugdb/jira/MB-11780/f4673f14/10.3.3.218-7192014-753-diag.zip
10.3.3.240 : https://s3.amazonaws.com/bugdb/jira/MB-11780/066eb643/10.3.3.240-diag.txt.gz
10.3.3.240 : https://s3.amazonaws.com/bugdb/jira/MB-11780/d169dc68/10.3.3.240-7192014-753-diag.zip

[Destination]
10.3.3.225 : https://s3.amazonaws.com/bugdb/jira/MB-11780/481a8e90/10.3.3.225-7192014-754-diag.zip
10.3.3.225 : https://s3.amazonaws.com/bugdb/jira/MB-11780/566270c9/10.3.3.225-diag.txt.gz
10.3.3.239 : https://s3.amazonaws.com/bugdb/jira/MB-11780/52202c4f/10.3.3.239-7192014-754-diag.zip
10.3.3.239 : https://s3.amazonaws.com/bugdb/jira/MB-11780/7107d70c/10.3.3.239-diag.txt.gz

Issue occurred on 10.3.3.239, which was destination master.
Is this a Regression?: Unknown

 Description   
1. Test failed before upgrade only.
2. Installed Source and Destination nodes 2.0.0-1976-rel
3. Changed global xdcr settings xdcrFailureRestartInterval=1 and xdcrCheckpointInterval=60 on each cluster.
3. Created remote clusters cluster0 and cluster1 for bi-directional XDCR.
4. Node 10.3.3.239 (Destination master) node become un-responsive.

[Notes]
1. Test worked fine for CentOS.
2. 3 tests are failed because of this issue, all are related to 2.0.0-1976-rel upgrade to 3.0.

[Jenkins]
http://qa.hq.northscale.net/job/ubuntu_x64--36_01--XDCR_upgrade-P1/24/consoleFull

[Test]
./testrunner -i ubuntu_x64--36_01--XDCR_upgrade-P1.ini get-cbcollect-info=True,get-logs=False,stop-on-failure=False,get-coredumps=True,upgrade_version=3.0.0-973-rel,initial_vbuckets=1024 -t xdcr.upgradeXDCR.UpgradeTests.offline_cluster_upgrade,initial_version=2.0.0-1976-rel,sdata=False,bucket_topology=default:1>2;bucket0:1><2,upgrade_nodes=dest;src,use_encryption_after_upgrade=src;dest


[Failure]
2014-07-19 07:50:28,182] - [basetestcase:264] INFO - sleep for 30 secs. ...
[2014-07-19 07:50:58,191] - [xdcrbasetests:1089] INFO - Setting xdcrFailureRestartInterval to 1 ..
[2014-07-19 07:50:58,204] - [rest_client:1726] INFO - Update internal setting xdcrFailureRestartInterval=1
[2014-07-19 07:50:58,262] - [rest_client:1726] INFO - Update internal setting xdcrFailureRestartInterval=1
[2014-07-19 07:50:58,263] - [xdcrbasetests:1089] INFO - Setting xdcrCheckpointInterval to 60 ..
[2014-07-19 07:50:58,278] - [rest_client:1726] INFO - Update internal setting xdcrCheckpointInterval=60
[2014-07-19 07:50:58,382] - [rest_client:1726] INFO - Update internal setting xdcrCheckpointInterval=60
[2014-07-19 07:50:58,392] - [rest_client:828] INFO - adding remote cluster hostname:10.3.3.239:8091 with username:password Administrator:password name:cluster1 to source node: 10.3.3.240:8091
[2014-07-19 07:50:58,780] - [rest_client:828] INFO - adding remote cluster hostname:10.3.3.240:8091 with username:password Administrator:password name:cluster0 to source node: 10.3.3.239:8091
[2014-07-19 07:50:59,048] - [rest_client:874] INFO - starting continuous replication type:capi from default to default in the remote cluster cluster1
[2014-07-19 07:50:59,250] - [basetestcase:264] INFO - sleep for 5 secs. ...
[2014-07-19 07:51:04,256] - [rest_client:874] INFO - starting continuous replication type:capi from bucket0 to bucket0 in the remote cluster cluster1
[2014-07-19 07:51:04,559] - [basetestcase:264] INFO - sleep for 5 secs. ...
[2014-07-19 07:51:15,538] - [rest_client:747] ERROR - http://10.3.3.239:8091/nodes/self error 500 reason: unknown ["Unexpected server error, request logged."]
http://10.3.3.239:8091/nodes/self with status False: [u'Unexpected server error, request logged.']
[2014-07-19 07:51:15,538] - [xdcrbasetests:139] ERROR - list indices must be integers, not str
[2014-07-19 07:51:15,539] - [xdcrbasetests:140] ERROR - Error while setting up clusters: (<type 'exceptions.TypeError'>, TypeError('list indices must be integers, not str',), <traceback object at 0x31dd7a0>)
[2014-07-19 07:51:15,540] - [xdcrbasetests:179] INFO - ============== XDCRbasetests cleanup is started for test #11 offline_cluster_upgrade ==============


 Comments   
Comment by Sangharsh Agarwal [ 22/Jul/14 ]
Logs from 10.3.3.239 at that duration:

[ns_server:debug,2014-07-19T7:50:40.998,ns_1@10.3.3.239:couch_stats_reader-bucket0<0.1006.0>:couch_stats_reader:vbuckets_aggregation_loop:126]Failed to open vbucket: 0 ({not_found,no_db_file}). Ignoring
[ns_server:debug,2014-07-19T7:50:41.137,ns_1@10.3.3.239:<0.995.0>:mc_connection:do_notify_vbucket_update:112]Signaled mc_couch_event: {set_vbucket,"bucket0",843,active,0}
[ns_server:debug,2014-07-19T7:50:41.142,ns_1@10.3.3.239:couch_stats_reader-bucket0<0.1006.0>:couch_stats_reader:vbuckets_aggregation_loop:126]Failed to open vbucket: 1 ({not_found,no_db_file}). Ignoring
[ns_server:debug,2014-07-19T7:50:41.143,ns_1@10.3.3.239:couch_stats_reader-bucket0<0.1006.0>:couch_stats_reader:vbuckets_aggregation_loop:126]Failed to open vbucket: 2 ({not_found,no_db_file}). Ignoring
[ns_server:debug,2014-07-19T7:50:41.139,ns_1@10.3.3.239:capi_set_view_manager-bucket0<0.979.0>:capi_set_view_manager:handle_info:377]Usable vbuckets:
[997,933,869,984,920,856,971,907,843,958,894,1022,945,881,1009,996,964,932,
 900,868,983,951,919,887,855,1015,970,938,906,874,1002,989,957,925,893,861,
 1021,976,944,912,880,848,1008,995,963,931,899,867,982,950,918,886,854,1014,
 969,937,905,873,1001,988,956,924,892,860,1020,975,943,911,879,847,1007,994,
 962,930,898,866,981,949,917,885,853,1013,968,936,904,872,1000,987,955,923,
 891,859,1019,974,942,910,878,846,1006,993,961,929,897,865,980,948,916,884,
 852,1012,999,967,935,903,871,986,954,922,890,858,1018,973,941,909,877,845,
 1005,992,960,928,896,864,979,947,915,883,851,1011,998,966,934,902,870,985,
 953,921,889,857,1017,972,940,908,876,844,1004,991,959,927,895,863,1023,978,
 946,914,882,850,1010,965,901,952,888,1016,939,875,1003,990,926,862,977,913,
 849]
[ns_server:debug,2014-07-19T7:50:41.150,ns_1@10.3.3.239:couch_stats_reader-bucket0<0.1006.0>:couch_stats_reader:vbuckets_aggregation_loop:126]Failed to open vbucket: 3 ({not_found,no_db_file}). Ignoring
[ns_server:debug,2014-07-19T7:50:41.158,ns_1@10.3.3.239:couch_stats_reader-bucket0<0.1006.0>:couch_stats_reader:vbuckets_aggregation_loop:126]Failed to open vbucket: 4 ({not_found,no_db_file}). Ignoring
[views:debug,2014-07-19T7:50:41.246,ns_1@10.3.3.239:mc_couch_events<0.428.0>:capi_set_view_manager:handle_mc_couch_event:529]Got set_vbucket event for bucket0/842. Updated state: active (0)
Comment by Sangharsh Agarwal [ 23/Jul/14 ]
Problem appeared on ubuntu platform only.




[MB-11784] GUI incorrectly displays vBucket number in stats Created: 22/Jul/14  Updated: 25/Jul/14

Status: Open
Project: Couchbase Server
Component/s: UI
Affects Version/s: 2.5.1, 3.0, 3.0-Beta
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Ian McCloy Assignee: Pavel Blagodov
Resolution: Unresolved Votes: 0
Labels: customer, supportability
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File 251VbucketDisplay.png     PNG File 3fixVbucketDisplay.png    
Issue Links:
Dependency
Triage: Untriaged
Is this a Regression?: Unknown

 Description   
Many customers are confused and have complained that on the "General Bucket Analytics" / "VBUCKET RESOURCES" page when listing the number of vBuckets, the GUI tries to convert the value 1024 default vBuckets to kilobytes, so it displays as 1.02k vBuckets (screen shot attached) . vBuckets shouldn't be parsed and always should show the full number.

I've changed the javascript to detect for vBuckets values and not parse them, (screen shot attached) . Will amend with a gerrit link when it's pushed to review.

 Comments   
Comment by Ian McCloy [ 22/Jul/14 ]
Code added to gerrit for review -> http://review.couchbase.org/#/c/39668/
Comment by Pavel Blagodov [ 24/Jul/14 ]
Hi Ian, here is clarification:
- kilo (or 'K') is a unit prefix in the metric system denoting multiplication by one thousand.
- kilobyte (or 'KB') is a multiple of the unit byte for digital information.
Comment by Ian McCloy [ 24/Jul/14 ]
Pavel thank you for clearing that up for me. Can you please explain when I see 1.02K vBuckets in the stats is that 1022, 1023 or 1024 active vBuckets, I'm not clear when I look at the UI.
Comment by Pavel Blagodov [ 25/Jul/14 ]
1.02K is expected value because currently UI truncates all analytic stats to three digits. Of course we may increase this number to four digits but this will be working only for K (not for M for example).
Comment by David Haikney [ 25/Jul/14 ]
@Pavel - Yes 1.02k is currently expected but the desire here is to change the UI to show "1024" instead of "1.02K". Fewer characters and more accuracy.




[MB-11831] a doc gets added but not indexed Created: 28/Jul/14  Updated: 28/Jul/14

Status: Open
Project: Couchbase Server
Component/s: secondary-index
Affects Version/s: 2.5.1
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Milan Simonovic Assignee: Sriram Melkote
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: tested on ubuntu 14.04 64bit

Triage: Untriaged
Flagged:
Impediment
Is this a Regression?: Unknown

 Description   
code to reproduce the bug: https://github.com/mbsimonovic/couchbase-bugs




[MB-11838] Rename upr to dcp in couchdb Created: 29/Jul/14  Updated: 29/Jul/14

Status: Open
Project: Couchbase Server
Component/s: None
Affects Version/s: 3.0
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Major
Reporter: Nimish Gupta Assignee: Nimish Gupta
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Triage: Untriaged
Is this a Regression?: Unknown




[MB-11826] Don't send unnecessary config updates. Created: 26/Jul/14  Updated: 28/Jul/14

Status: Open
Project: Couchbase Server
Component/s: couchbase-bucket
Affects Version/s: 3.0-Beta
Fix Version/s: None
Security Level: Public

Type: Bug Priority: Minor
Reporter: Brett Lawson Assignee: Chiyoung Seo
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Triage: Untriaged
Is this a Regression?: No

 Description   
The memcached service should keep track of the last revId that it sent to a client who is connected, and avoid dispatching an identical config to the client during a NMV. Currently, when pipelining operations, a client may receive hundreds of NMV responses when only a single one is necessary. This won't prevent multiple NMV's across nodes, but will prevent the bulk of the spam.

Note: An explicit request for the config via CCCP_GET_VBUCKET_CONFIG should always return the data regardless of revId info.

 Comments   
Comment by Jeff Morris [ 28/Jul/14 ]
This would alleviate the "spam" problem with configs during rebalance/swap/failover scenarios. +1.




Generated at Tue Jul 29 00:55:23 CDT 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.