Breadcrumb API is not thread-safe

[dtorres]

Description

While running our app under the thread sanitiser, it frequently hits a race condition on the Breadcrumb API as seen here:

Issue

Environment

Library versions:

• Bugsnag version (from your Podfile, Podfile.lock, or elsewhere):
• CocoaPods version (if any) (pod -v):
• Carthage version (if any):
• iOS/tvOS/macOS version(s)
• debug mode or production?:
• How are you initializing Bugsnag? Can you share a snippet of your
  AppDelegate where Bugsnag is configured?

Example code snippet

import Bugsnag

// (Insert code sample to reproduce the problem)

Error messages:

[mattdyoung]

Thanks for the report @dtorres. I can reproduce this so we'll take a look and try to determine the cause.

Have you seen any evidence of this causing crashes or other issues or has it just been flagged by thread sanitizer so far?

Until we can identify a fix, you may be able to work around this by using your own FIFO queue (e.g. NSOperationQueue with a maxConcurrentOperationCount count of 1) for calling leaveBreadcrumb().

[dtorres]

Thanks for the report @dtorres. I can reproduce this so we'll take a look and try to determine the cause.

Have you seen any evidence of this causing crashes or other issues or has it just been flagged by thread sanitizer so far?

We haven't seen this particular stack trace as a crash yet but a memory corruption issue (such as this) can cause other pieces of code to crash if they are unlucky enough to step on that same memory address later.

This race condition is now more likely to happen in our app as we have backgrounded most calls to the breadcrumb API as it isn't suited for main thread use (See #563).

Until we can identify a fix, you may be able to work around this by using your own FIFO queue (e.g. NSOperationQueue with a maxConcurrentOperationCount count of 1) for calling leaveBreadcrumb().

We are wrapping the calls inside of a lock to work around this.

[mattdyoung]

Understood. We'll need to investigate further on our side to determine the best way to fix. I'll update this issue when we know more.

[iwasrobbed-ks]

I saw this as well today and it's basically because you're writing a new breadcrumb within readWriteQueue but then not protecting reads for breadcrumbs within the same readWriteQueue. That violates the read/write approach that you all took since reads need equal protection

[johnkiely1]

@rob-keepsafe

Thanks for this, we will review and update this issue as necessary.

[RuiAAPeres]

Any luck on this?

[johnkiely1]

This has now been fixed in V6.1.1