Problem with dotnet core library 2.6.1


#1

Currently i an using lib version 2.5.12. When I upgraded to 2.6.1 i got tracing error. I didnt find any other way to report this error, only throught forum.

here is stack trace
Destination array was not long enough. Check the destination index, length, and the array’s lower bounds.
Parameter name: destinationArray

Exception: System.ArgumentException

source: System.Private.CoreLib
target: Copy
module: System.Private.CoreLib.dll

at System.Array.Copy(Array sourceArray, Int32 sourceIndex, Array destinationArray, Int32 destinationIndex, Int32 length, Boolean reliable)
at System.Collections.Generic.List1.CopyTo(T[] array, Int32 arrayIndex) at System.Collections.Generic.List1…ctor(IEnumerable1 collection) at System.Linq.Enumerable.ToList[TSource](IEnumerable1 source)
at Couchbase.Tracing.SpanSummary.PopulateSummary(IEnumerable1 spans) at Couchbase.Tracing.SpanSummary..ctor(Span span) at Couchbase.Tracing.ThresholdLoggingTracer.ReportSpan(Span span) at Couchbase.Core.Buckets.CouchbaseRequestExecuter.SendWithRetryAsync[T](IOperation1 operation, TaskCompletionSource`1 tcs, CancellationTokenSource cts)
at Shared.CouchbaseClient.CouchbaseClient.GetAsync[T](String key) in c:\workspace\4OBackend_GIT\src\Lib.Shared\CouchbaseClient\CouchbaseClient.cs:line 515
at Backend.ObjectStorage.Tags.TagsStorageProvider.GetTagsAsync(Int64 userAccountId, String objectId) in c:\workspace\4OBackend_GIT\src\Lib.Backend\ObjectStorage\Tag\TagsStorageProvider.cs:line


#2

Hi @luka

The error seems to be when ToList() is called, the source and destination array’s are not the same length, meaning the source ISpan collection has been modified between creating the copy and starting to copy the contents. This seems very odd to me and is definitely something I have not observed before.

Please can you provide more context to the following:

  • Couchbase server version
  • Application environment (ASP.NET vs standalone process, .NET full vs .NET Core, etc)
  • What operation(s) are you executing to get this behaviour? (KV, N1QL, FTS, etc)
  • Can you provide a SDK log?

Thanks


#3

Regarding your comment on the commit that we provided to try and prevent a Collection Change Exception here.

Limiting recursion depth is an option, but I don’t think we should have that many recursions. The normal hierarchy I’ve observed would look like this:

Span (parent - initial call into Couchbase)
  | - Span (attempt x, repeats per attempt)
      | - Span (encode, if required)
      | - Span (dispatch to server, including server duration tag if available)
      | - Span (decode, if required)

Here there are only 3 levels of recursion, but there could be an increased array length in the middle when there are many attempts.


#4

More info

  • i am using server Community Edition 5.1.1
  • application environment .net core (error occours in both os platform windows, linux when our test was running)
  • operation was KV (CouchbaseClient.GetAsync[T](String key) )
  • sorry i dont have sdk logs.

the system was under pressure because our test runs parrallel. we are using multiolex io connections.


#5

Okay - I’ll take a look to see if I can reproduce the issue.

Are you getting any other information / exceptions in the same area? eg timeouts? A SDK log would be really useful if you could provide one.

We already have the JIRA ticket NCBC-1745 to investigate this defect - I’ll use this to report progress & fixes.

In the meantime, you can disable tracing by setting OperationTracingEnabled either programmatically in the ClientConfiguration or in the web/app.config property operationTracingEnabled to false.