Please triage, we couldn't find a better owner.

Sounds like nothing can be done before repro steps aren't here.

Sounds like you're running an old version of base because this stack is no longer possible (SchedulerWorker::RunWorker() is the one releasing this scoped_refptr now).

Also, sounds like you're embedding //base which is not officially supported (community contributions welcome if you find a real bug in our code though).

Re#3:

Thanks for your information. We are using version 65.0.3325.152 actually so probably it is fixed in the newest version and I will upgrade it soon.

'you're embedding //base which is not officially supported', do you mean I should exclude //base from the dependencies? I used the following gn command to generate our static lib, how should I modify it to avoid embedding //base? Thanks!

gn gen out/Release-iphoneos --args='is_cronet_build=true enable_reporting=false use_xcode_clang=true ios_deployment_target="9.0" target_cpu="arm" target_os="ios" enable_websockets=false disable_file_support=true disable_ftp_support=true disable_brotli_filter=true use_platform_icu_alternatives=true is_component_build=false ios_enable_code_signing=false is_debug=false use_partition_alloc=false include_transport_security_state_preload_list=false is_official_build=true enable_dsyms=true enable_stripping=true symbol_level=0 additional_target_cpus=["arm64"]' --ide=xcode

Is this a fork of Chromium? What is unexpected here is that the binary image is called Snapchat.

Re #5:

No, but we use Cronet library as our network stack. And we build the Cronet static lib using the command mentioned above.

In that case, we recommend your original proposal in #4 to upgrade to the latest version.

Re #7:

Sure. I am going to upgrade Cronet to version 69.0.3497.91 (latest stable version for iOS). Just want to confirm that this version has SchedulerWorker::RunWorker() as the one releasing the scoped_refptr. Thanks!

We are still hitting this issue (same crash stack) with Cronet 69.0.3497.91. This seems to be only affecting iOS 10.

Are you able to tell whether it is this line that crashes? https://cs.chromium.org/chromium/src/base/threading/platform_thread_posix.cc?l=239&rcl=544c743d07cdb417b9ad4289025eae9d6fddffb7

It would be useful to know what the return value of pthread_detach() is and also what the value of |thread_handle| is.

Snapchat is still reporting it as happening in Cronet on iOS 10.

gab@: Snap is embedding Cronet (//components/cronet/ios), which includes //base, //net, and some other stuff.

jni@: Just to confirm, are you're using Cronet static framework (linking into Snapchat app) as opposed to dynamic Cronet.framework?

Re #10:
Yes it seems to be the CHECK_EQ macro crashing the app. We are wondering would it be OK to remove CHECK_EQ there?

Re #11:
Correct, we are using static framework.

If pthread_detach() isn’t returning 0, what is it returning?

Re #13:
Since we are using static cronet lib and linking it to our app, it is not easy to get the return value of pthread_detach. Is there any recommended way of how we get it? thanks!