NetworkConnectionInfoProvider EXC_BAD_ACCESS crash on data upload

[fddecc]

Describe what happened

Crashed: com.datadoghq.ios-sdk-logs-upload
EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000020

We are seeing two separate but likely related crashes. Limited stack traces included below.

1
Datadog
$s7Datadog29NetworkConnectionInfoProviderC7currentAA0bcD0Vvg + 152
2
Datadog
$s7Datadog20DataUploadConditionsV010canPerformC0SbyF + 180
3
Datadog
$s7Datadog16DataUploadWorkerC012scheduleNextC004_2E3G27D1790FB5C692514696637CC9BCBLL5afterySd_tFyycfU_ + 600

and

2
Datadog
$s7Network13NWPathMonitorC7DatadogE15currentPathInfoAD09NWCurrentfG0VyF + 132
3
Datadog
$s7Datadog29NetworkConnectionInfoProviderC7currentAA0bcD0Vvg + 152
4
Datadog
$s7Datadog20DataUploadConditionsV010canPerformC0SbyF + 180
5
Datadog
$s7Datadog16DataUploadWorkerC012scheduleNextC004_2E3G27D1790FB5C692514696637CC9BCBLL5afterySd_tFyycfU_ + 600

Will try to provide more detailed stack traces if available.

Steps to reproduce the issue:
Unknown

Expected behaviour:
No crash

Actual behaviour:
Crash; numbers till limited, but not negligible

Additional context

• OS version and device model: across various models os versions
• Datadog SDK version: latest beta
• an explanation of what might cause the bug and/or how it can be fixed: unknown, but about 40-45% of crashes are in background

[ncreated]

Hello @00FA9A , thanks for all the details 👍.

Datadog SDK version: latest beta

Do you have any numbers from any prior version? In 1.0.0-beta3 we modified NetworkConnectionInfoProvider which appears in the stack trace, this would be very handy to know if this is a regression 🙏.

Second, does it happen on iOS 11 or it's iOS 12+? We have different implementation of network info provider for both versions.

[fddecc]

@ncreated I should have been more clear - this was on 1.0.0-beta2; based on our data its primarily iOS 13, and small subset (around 4%) on iOS 12. We do not support iOS 11

[ncreated]

Clear 👍. We will investigate this stack trace in -beta2 and see if this was fixed in -beta3. No matter of that - please consider upgrading to recent 1.0.1 as it ships another crash fix that may impact your users.

Speaking on crash:

EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x0000000000000020

this address looks almost like a tagged pointer. What's the Xcode version you use for App Store builds?

[fddecc]

@ncreated we use 11C504 - 11.3.1 for our builds at the moment.

Running into Could not resolve package dependencies: package has unsupported layout; modulemap '.../Carthage/Checkouts/dd-sdk-ios/Datadog/DatadogPrivate/module.modulemap' should be inside the 'include' directory on 1.0.1 and even beta3 when attempting to update this dependency via Carthage. is this expected? I see some prs that were supposed to remedy this

[ncreated]

Running into Could not resolve package dependencies: package has unsupported layout; modulemap '.../Carthage/Checkouts/dd-sdk-ios/Datadog/DatadogPrivate/module.modulemap' should be inside the 'include' directory on 1.0.1

This is highly unexpected. We added vanilla Carthage project fixture and carthage update works fine on it.

1/ What's the Carthage version you use (carthage version)?
2/ This error doesn't seem to come from Carthage, do you also link SPM dependencies somehow to your project?

[fddecc]

@ncreated we currently use 0.34.0 and dont have any SPM dependencies. full error is:

A shell task (/usr/bin/xcrun xcodebuild -workspace /Users/.../Carthage/Checkouts/dd-sdk-ios/instrumented-tests/Integration/Integration.xcworkspace CODE_SIGNING_REQUIRED=NO CODE_SIGN_IDENTITY= CARTHAGE=YES -list) failed with exit code 74:
xcodebuild: error: Could not resolve package dependencies:
  package has unsupported layout; modulemap '/Users/.../Carthage/Checkouts/dd-sdk-ios/Datadog/DatadogPrivate/module.modulemap' should be inside the 'include' directory

continuing to look if its some other issue, but just wanted to let you know

[ncreated]

@00FA9A I'm trying to reproduce it. Does it come from plain carthage update command or you use some additional parameters?

[fddecc]

@00FA9A I'm trying to reproduce it. Does it come from plain carthage update command or you use some additional parameters?

both plain version as well as with --platform iOS fail

[ncreated]

About the Carthage issue - #71 was opened, it gives more details. We're on it.

[ncreated]

I think this might be fixed in 1.0.0-beta3 as we migrated from unreliable concurrent queue:

dd-sdk-ios/Sources/Datadog/Core/System/NetworkConnectionInfoProvider.swift

Line 43 in 68fac65

private let queue = DispatchQueue.global(qos: .utility)

to serial queue:

dd-sdk-ios/Sources/Datadog/Core/System/NetworkConnectionInfoProvider.swift

Lines 61 to 66 in 8880e1d

	let queue = DispatchQueue(
	label: "com.datadoghq.network-connection-info",
	qos: .utility,
	attributes: [],
	target: DispatchQueue.global(qos: .utility)
	)

for processing the NWPathMonitor calls.

@00FA9A please upgrade to recent version (1.0.2 while I'm writing) and let us know if the crash was gone 🙏.