[Crash] PHTFlatFilePhenotype

I'm using firebase 6.8.1, Admob 7.49.0. All componets are newest.
When new App is released at Appstore, I found more crashs appear in firebase dashboard. I do not use ProtoBuf directly
I updated all Pods, before upload package to Appstore. All componets are newest.
Crashed: PHTFlatFilePhenotype
0  Protobuf                       0x160efd8 GPBCodedInputStreamReadDouble + 88 (GPBUtilities_PackagePrivate.h:88)
1  Protobuf                       0x160efd1 GPBCodedInputStreamReadDouble + 103 (GPBCodedInputStream.m:103)
2  Protobuf                       0x1639fd1 -[GPBMessage mergeFromCodedInputStream:extensionRegistry:] + 2143 (GPBMessage.m:2143)
3  Protobuf                       0x160f9c5 -[GPBCodedInputStream readMessage:extensionRegistry:] + 296 (GPBCodedInputStream.m:296)
4  Protobuf                       0x163a47f MergeRepeatedNotPackedFieldFromCodedInputStream + 2294 (GPBMessage.m:2294)
5  Protobuf                       0x1639f6b -[GPBMessage mergeFromCodedInputStream:extensionRegistry:] + 2393 (GPBMessage.m:2393)
6  Protobuf                       0x160f9c5 -[GPBCodedInputStream readMessage:extensionRegistry:] + 296 (GPBCodedInputStream.m:296)
7  Protobuf                       0x163a47f MergeRepeatedNotPackedFieldFromCodedInputStream + 2294 (GPBMessage.m:2294)
8  Protobuf                       0x1639f6b -[GPBMessage mergeFromCodedInputStream:extensionRegistry:] + 2393 (GPBMessage.m:2393)
9  Protobuf                       0x160f9c5 -[GPBCodedInputStream readMessage:extensionRegistry:] + 296 (GPBCodedInputStream.m:296)
10 Protobuf                       0x163a47f MergeRepeatedNotPackedFieldFromCodedInputStream + 2294 (GPBMessage.m:2294)
11 Protobuf                       0x1639f6b -[GPBMessage mergeFromCodedInputStream:extensionRegistry:] + 2393 (GPBMessage.m:2393)
12 Protobuf                       0x1639647 -[GPBMessage mergeFromData:extensionRegistry:] + 1928 (GPBMessage.m:1928)
13 Protobuf                       0x1636d55 -[GPBMessage initWithData:extensionRegistry:error:] + 868 (GPBMessage.m:868)
14 Protobuf                       0x163971b +[GPBMessage parseFromData:extensionRegistry:error:] + 1957 (GPBMessage.m:1957)
15 Protobuf                       0x16396e5 +[GPBMessage parseFromData:error:] + 1951 (GPBMessage.m:1951)
16 SparkMusic                     0x526773 __69-[PHTHeterodyneSyncer syncAccount:syncedScopes:fetchReason:callback:]_block_invoke_2 + 4831091
17 libdispatch.dylib              0x1b461797 _dispatch_call_block_and_release + 10
18 libdispatch.dylib              0x1b46e59d _dispatch_queue_serial_drain + 854
19 libdispatch.dylib              0x1b464b71 _dispatch_queue_invoke + 886
20 libdispatch.dylib              0x1b46ea1f _dispatch_queue_override_invoke + 282
21 libdispatch.dylib              0x1b4701b5 _dispatch_root_queue_drain + 326
22 libdispatch.dylib              0x1b47000f _dispatch_worker_thread3 + 106
23 libsystem_pthread.dylib        0x1b61687d _pthread_wqthread + 1040
24 libsystem_pthread.dylib        0x1b61645c start_wqthread + 8

Please share the Podfile and Podfile.lock.  Also, any other patterns in where the crashes occur like iOS versions, etc.

I am seeing the same crash on 2 apps.
The crashes appear to be from iOS 9 and iOS 10 only on both apps.
These builds were compiled with the Xcode 11 GM Seed.
@fangyuxi what version of Xcode did you compile the build with? (Just wondering if other users haven’t spotted this yet, or if it is an issue compiling against the Xcode 11 GM seed?)

@neilmorton  The Xcode version is 10.3. Not Xcode 11 GM.
Now, this problem has caused a lot of Crash.
(Just wondering if other users haven’t spotted this yet)
@paulb777 The specific compilation environment and podfile or podfile lock  will be available to you tomorrow.

@fangyuxi That’s interesting about the Xcode version.
Can you see what versions of iOS are affected for you? Are you seeing it limited to iOS 9 and 10?

@neilmorton  Yes iOS 9 and iOS 10 Only

@neilmorton Now I am concerned about whether this Crash will cause iOS 9 and iOS 10 users to not use the App properly(I don't have an iPhone for iOS9 or iOS 10 to test.). If the user only occasionally encounters this Crash, then we still have time to fix it.

@fangyuxi ok. I was limiting Firebase to 6.5.0 before my latest build due to a previous issue. I thought that was fixed, but seems there is now a new issue.
I am going to limit the pod file back to 6.5.0 and resubmit whilst this gets figured out.

@fangyuxi Looking at the data in Fabric I am sufficiently concerned by the number of iOS 9 / 10 users affected that I am reverting to the Firebase build that I had limited to due to the past issues.
Podfile update:
pod 'Firebase/Core', '~> 6.5.0'

@neilmorton Please check to see if these versions are stable? Thank you very much !
Installing AFNetworking (3.2.1)
Installing AppLovinSDK (6.8.0)
Installing BoringSSL-GRPC (0.0.3)
Installing CYLTabBarController (1.28.3)
Installing Crashlytics (3.14.0)
Installing DeviceUtil (5.1.0)
Installing FBAudienceNetwork (5.5.0)
Installing FBSDKCoreKit (5.6.0)
Installing FBSDKLoginKit (5.6.0)
Installing Fabric (1.10.2)
Installing Firebase (6.5.0)
Installing FirebaseABTesting (3.1.1)
Installing FirebaseAnalytics (6.0.4)
Installing FirebaseAnalyticsInterop (1.4.0)
Installing FirebaseAuth (6.2.1)
Installing FirebaseAuthInterop (1.0.0)
Installing FirebaseCore (6.1.0)
Installing FirebaseDatabase (6.0.0)
Installing FirebaseFirestore (1.4.2)
Installing FirebaseInstanceID (4.2.5)
Installing FirebaseMessaging (4.1.1)
Installing FirebasePerformance (3.1.1)
Installing FirebaseRemoteConfig (4.2.1)
Installing FirebaseStorage (3.4.1)
Installing FirebaseUI (8.0.4)
Installing Flurry-iOS-SDK (9.3.1)
Installing GTMSessionFetcher (1.2.2)
Installing Google-Mobile-Ads-SDK (7.49.0)
Installing GoogleAppMeasurement (6.0.4)
Installing GoogleMobileAdsMediationAppLovin (<IP_ADDRESS>)
Installing GoogleMobileAdsMediationFacebook (<IP_ADDRESS>)
Installing GoogleMobileAdsMediationInMobi (<IP_ADDRESS>)
Installing GoogleMobileAdsMediationMoPub (<IP_ADDRESS>)
Installing GoogleSignIn (4.4.0)
Installing GoogleToolboxForMac (2.2.1)
Installing GoogleUtilities (6.2.5)
Installing IQKeyboardManager (6.4.2)
Installing InMobiSDK (7.3.2)
Installing KVOController (1.2.0)
Installing LEEAlert (1.2.8)
Installing MJRefresh (3.2.0)
Installing MOBFoundation (3.2.5)
Installing Masonry (1.1.0)
Installing NMEasyTipView (1.2)
Installing Protobuf (3.9.0)
Installing RTRootNavigationController (0.6.7)
Installing Reachability (3.2)
Installing ReactiveCocoa (2.5)
Installing SDWebImage (5.1.1)
Installing SJBaseVideoPlayer (2.7.1)
Installing SJUIKit (<IP_ADDRESS>)
Installing SVProgressHUD (2.2.5)
Installing TOWebViewController (2.2.8)
Installing TTGTagCollectionView (1.11.1)
Installing YYCache (1.0.4)
Installing YYCategories (1.0.4)
Installing YYModel (1.0.4)
Installing gRPC-C++ (0.0.9)
Installing gRPC-Core (1.21.0)
Installing leveldb-library (1.22)
Installing lottie-ios (2.5.3)
Installing mob_sharesdk (4.3.2)
Installing mopub-ios-sdk (5.7.1)
Installing nanopb (0.3.901)

@fangyuxi
I am not sure what you want me to check, but what I can say is that the current config (with the issue) is:
Installing Firebase 6.8.1 (was 6.5.0)
Installing FirebaseABTesting 3.1.1 (was 3.1.0)
Installing FirebaseAnalytics 6.1.1 (was 6.0.4)
Using FirebaseAnalyticsInterop (1.4.0)
Installing FirebaseCore 6.2.3 (was 6.1.0)
Installing FirebaseCoreDiagnostics (1.0.1)
Installing FirebaseCoreDiagnosticsInterop (1.0.0)
Installing FirebaseInstanceID 4.2.5 (was 4.2.3)
Installing FirebasePerformance 3.1.4 (was 3.1.1)
Installing FirebaseRemoteConfig 4.4.0 (was 4.2.1)
Using GTMSessionFetcher (1.2.2)
Installing GoogleAppMeasurement 6.1.1 (was 6.0.4)
Installing GoogleDataTransport (1.2.0)
Installing GoogleDataTransportCCTSupport (1.0.3)
Using GoogleToolboxForMac (2.2.1)
Using GoogleUtilities (6.2.5)
Using Protobuf (3.9.0)
Using nanopb (0.3.901)

I have now locked Firebase back to 6.5.0 (reverted to what I was running previously):
Installing Firebase 6.5.0 (was 6.8.1)
Using FirebaseABTesting (3.1.1)
Installing FirebaseAnalytics 6.0.4 (was 6.1.1)
Using FirebaseAnalyticsInterop (1.4.0)
Installing FirebaseCore 6.1.0 (was 6.2.3)
Using FirebaseInstanceID (4.2.5)
Installing FirebasePerformance 3.1.1 (was 3.1.4)
Installing FirebaseRemoteConfig 4.2.1 (was 4.4.0)
Using GTMSessionFetcher (1.2.2)
Installing GoogleAppMeasurement 6.0.4 (was 6.1.1)
Using GoogleToolboxForMac (2.2.1)
Using GoogleUtilities (6.2.5)
Using Protobuf (3.9.0)
Using nanopb (0.3.901)
Removing FirebaseCoreDiagnostics
Removing FirebaseCoreDiagnosticsInterop
Removing GoogleDataTransport
Removing GoogleDataTransportCCTSupport

I have done this as there wasn't an issue previously and I want the iOS 9 and iOS 10 users back up and running.
Looking at your information, it seems that you have Installing FirebaseCore (6.1.0) shown.
Have you added the pod 'Firebase/Core', '~> 6.5.0' to your Podfile instead of the default and run pod update to get to this config? If so, then looking at the associated versions, then this looks to match with mine.
I hope this helps.

@neilmorton OK Thank you.

I believe that the backtrace shown would only come from FirebasePerformance.  Would you confirm if removing FirebasePerformance makes the crash stop occurring?

@paulb777
It seems that this Crash only come from FirebasePerformance, but now I am ready to roll back the version to 6.7.0. Because there are too many users showing this Crash.I guess that after removing FirebasePerformance, the Crash should not appear, but updating the app version takes time, affects many users, so dare not try to remove FirebasePerformance.
Thank you.
Also, if this is configured(pod 'Firebase/Core', '~> 6.7.0'), will all the dependent Pods roll back to 6.7.0?
Installing Fabric (1.10.2)
Installing Firebase (6.7.0)
Installing FirebaseABTesting (3.1.1)
Installing FirebaseAnalytics (6.1.1)
Installing FirebaseAnalyticsInterop (1.4.0)
Installing FirebaseAuth (6.2.3)
Installing FirebaseAuthInterop (1.0.0)
Installing FirebaseCore (6.2.1)
Installing FirebaseCoreDiagnostics (1.0.1)
Installing FirebaseCoreDiagnosticsInterop (1.0.0)
Installing FirebaseDatabase (6.1.0)
Installing FirebaseFirestore (1.4.5)
Installing FirebaseInstanceID (4.2.5)
Installing FirebaseMessaging (4.1.4)
Installing FirebasePerformance (3.1.2)
Installing FirebaseRemoteConfig (4.3.0)
Installing FirebaseStorage (3.4.1)
Installing FirebaseUI (8.0.4)
Installing Flurry-iOS-SDK (9.3.1)
Installing GTMSessionFetcher (1.2.2)
Installing Google-Mobile-Ads-SDK (7.49.0)
Installing GoogleAppMeasurement (6.1.1)
Installing GoogleDataTransport (1.2.0)
Installing GoogleDataTransportCCTSupport (1.0.4)
Installing GoogleMobileAdsMediationAppLovin (<IP_ADDRESS>)
Installing GoogleMobileAdsMediationFacebook (<IP_ADDRESS>)
Installing GoogleMobileAdsMediationInMobi (<IP_ADDRESS>)
Installing GoogleMobileAdsMediationMoPub (<IP_ADDRESS>)
Installing GoogleSignIn (4.4.0)
Installing GoogleToolboxForMac (2.2.1)
Installing GoogleUtilities (6.2.5)
Thank you again.

@neilmorton OK Thank you.

You are welcome @fangyuxi

I believe that the backtrace shown would only come from FirebasePerformance. Would you confirm if removing FirebasePerformance makes the crash stop occurring?

@paulb777 Unfortunately I am in the same position as @fangyuxi. I had issues after moving up past 6.5.0 previously in that I was seeing a raft of GDTUploadCoordinator.m crashes. At that point there was a comment from yourself that suggested reverting to 6.5.0 https://github.com/firebase/firebase-ios-sdk/issues/3547#issuecomment-520151994.
I had just made the decision to lift that version hold with this latest release to now experience this new issue across 4 apps with the latest builds ready for iOS 13.
I don't really want to risk just removing FirebasePerformance in case there is still an issue.
Rather I have, as mentioned above, locked them all back to 6.5.0. In the meantime I shall consider the options!

Also, if this is configured(pod 'Firebase/Core', '~> 6.7.0'), will all the dependent Pods roll back to 6.7.0?

@fangyuxi If you run pod update after making the change in the Podfile, then it should manage the dependencies, yes.

If you run pod install, versions of existing pods won't necessarily change.
if you run pod update, versions will update to the latest unless there are version specifications in the Podfile.
pod 'Firebase/Core', '~> 6.7.0' indicates to use the latest Firebase pod at version 6.7.*.  The Firebase pod specifies that its dependencies can do patch updates.
Thus if you do a pod update with pod 'Firebase/Core', '~> 6.7.0' you will get `FirebasePerformance 3.1.4 even though 6.7.0 released with 3.1.3.
@fangyuxi It looks like you still have 3.1.2. Please confirm the issue is still occurring with 3.1.4.

Hi @paulb777
I have obtained the details of this app build binary. Hope to help.
This is the details of the App that has Crash.
-Xcode Version 10.2.1
-Base SDK iOS 12.2
-Crash iOS Version iOS9, iOS10 only.

The pod install info.

Yes, iOS 10 -> iOS 13

Thanks for the additional data about iOS versions.
It seems that this is an issue for iOS 9 and  iOS 10.  Maybe also iOS 8?

My lowest supported build is iOS 9, and iOS 9 and 10 are affected for me. As you say, it could be for 8 too, but I can’t say, sorry.

Hello,
We are also got same issue here.
We haven't change firebase version since 3 months ago and the problem just start occurred since September 13th.
Is it possible that the problem is form BE side?
pod 'Firebase/Core', '= 6.2.0'
pod 'Firebase/Analytics', '= 6.2.0'
pod 'Firebase/Performance', '= 6.2.0'

My lowest platform support is iOS 10.

Hello,
Same issue here but ours is also impacting iOS 11 and 12.
Having said that it's massively skewed towards iOS 10 (67%), not sure about iOS 9.x (we only support 10.2 and above).
Looking at the device range affected it's 70% iPhone 5 series.
These are always aligned so hard to tell if it's the device or the OS making it more likely to happen.
It only started occurring for us when we released custom tracing for the first time on 14th September. It hasn't happened for any other versions, this would seem to indicate something wrong with custom performance tracing. The following are the Firebase versions we're using:
    pod 'Firebase/Analytics', '~> 6.2.0'
    pod 'Firebase/Core', '~> 6.2.0'
    pod 'Firebase/Performance', '~> 6.2.0'
    pod 'Firebase/RemoteConfig', '~> 6.2.0'

We're going to remove custom tracing until we can figure out what this issue is.

Internally tracked at b/141097962

Hi  @patrickmarshall
Can you share your Podfile and Podfile.lock?

Maybe related. More crashes started with our new release, ios 10 & ios 9 only:
Crashed: com.google.firebase.firestore
0  chatium                        0x3574e0 GPBCodedInputStreamReadDouble + 88 (GPBUtilities_PackagePrivate.h:88)
1  chatium                        0x3574d9 GPBCodedInputStreamReadDouble + 103 (GPBCodedInputStream.m:103)
2  chatium                        0x382415 -[GPBMessage mergeFromCodedInputStream:extensionRegistry:] + 2143 (GPBMessage.m:2143)
3  chatium                        0x357eb5 -[GPBCodedInputStream readMessage:extensionRegistry:] + 296 (GPBCodedInputStream.m:296)
4  chatium                        0x382593 -[GPBMessage mergeFromCodedInputStream:extensionRegistry:] + 2181 (GPBMessage.m:2181)
5  chatium                        0x357eb5 -[GPBCodedInputStream readMessage:extensionRegistry:] + 296 (GPBCodedInputStream.m:296)
6  chatium                        0x382593 -[GPBMessage mergeFromCodedInputStream:extensionRegistry:] + 2181 (GPBMessage.m:2181)
7  chatium                        0x357eb5 -[GPBCodedInputStream readMessage:extensionRegistry:] + 296 (GPBCodedInputStream.m:296)
8  chatium                        0x3828c3 MergeRepeatedNotPackedFieldFromCodedInputStream + 2294 (GPBMessage.m:2294)
9  chatium                        0x3823af -[GPBMessage mergeFromCodedInputStream:extensionRegistry:] + 2393 (GPBMessage.m:2393)
10 chatium                        0x357eb5 -[GPBCodedInputStream readMessage:extensionRegistry:] + 296 (GPBCodedInputStream.m:296)
11 chatium                        0x382593 -[GPBMessage mergeFromCodedInputStream:extensionRegistry:] + 2181 (GPBMessage.m:2181)
12 chatium                        0x357eb5 -[GPBCodedInputStream readMessage:extensionRegistry:] + 296 (GPBCodedInputStream.m:296)
13 chatium                        0x382593 -[GPBMessage mergeFromCodedInputStream:extensionRegistry:] + 2181 (GPBMessage.m:2181)
14 chatium                        0x357eb5 -[GPBCodedInputStream readMessage:extensionRegistry:] + 296 (GPBCodedInputStream.m:296)
15 chatium                        0x382593 -[GPBMessage mergeFromCodedInputStream:extensionRegistry:] + 2181 (GPBMessage.m:2181)
16 chatium                        0x357eb5 -[GPBCodedInputStream readMessage:extensionRegistry:] + 296 (GPBCodedInputStream.m:296)
17 chatium                        0x382593 -[GPBMessage mergeFromCodedInputStream:extensionRegistry:] + 2181 (GPBMessage.m:2181)
18 chatium                        0x381a8b -[GPBMessage mergeFromData:extensionRegistry:] + 1928 (GPBMessage.m:1928)
19 chatium                        0x37f199 -[GPBMessage initWithData:extensionRegistry:error:] + 868 (GPBMessage.m:868)
20 chatium                        0x381b5f +[GPBMessage parseFromData:extensionRegistry:error:] + 1957 (GPBMessage.m:1957)
21 chatium                        0x381b29 +[GPBMessage parseFromData:error:] + 1951 (GPBMessage.m:1951)
22 chatium                        0x2a7005 firebase::firestore::local::LevelDbQueryCache::DecodeTarget(absl::string_view) + 374 (leveldb_query_cache.mm:374)
23 chatium                        0x2a6bfd firebase::firestore::local::LevelDbQueryCache::GetTarget(FSTQuery*) + 164 (leveldb_query_cache.mm:164)
24 chatium                        0x251543 -[FSTLocalStore allocateQuery:] + 436 (FSTLocalStore.mm:436)
25 chatium                        0x27dd97 -[FSTSyncEngine listenToQuery:] + 221 (FSTSyncEngine.mm:221)
26 chatium                        0x2304c7 -[FSTEventManager addListener:] + 123 (FSTEventManager.mm:123)
27 chatium                        0x23d7b5 std::__1::__function::__func<-[FSTFirestoreClient listenToQuery:options:listener:]::$_8, std::__1::allocator<-[FSTFirestoreClient listenToQuery:options:listener:]::$_8>, void ()>::operator()() + 4517 (memory:4517)
28 chatium                        0x1f4dd1 firebase::firestore::util::AsyncQueue::ExecuteBlocking(std::__1::function<void ()> const&) + 1913 (functional:1913)
29 chatium                        0x20b189 firebase::firestore::util::internal::DispatchAsync(NSObject<OS_dispatch_queue>*, std::__1::function<void ()>&&)::$_0::__invoke(void*) + 1862 (functional:1862)
30 libdispatch.dylib              0x1da65ec5 _dispatch_queue_serial_drain + 840
31 libdispatch.dylib              0x1da5c379 _dispatch_queue_invoke + 566
32 libdispatch.dylib              0x1da6635d _dispatch_queue_override_invoke + 286
33 libdispatch.dylib              0x1da67a91 _dispatch_root_queue_drain + 378
34 libdispatch.dylib              0x1da678b7 _dispatch_worker_thread3 + 106
35 libsystem_pthread.dylib        0x1dc0e937 _pthread_wqthread + 1168
36 libsystem_pthread.dylib        0x1dc0e48c start_wqthread + 8

Hi I have same issues with this , and its crash only for iOS 10 iPhone 5 @paulb777

@Strate That does not seem to be related to this. Thanks for bring this to attention though. Can you create a separate issue to track that thread?
The recent changes to Firebase Performance SDK is not related to the stack trace shown. Seem to be a dependency issue. I will keep the group posted on the findings. We are working to make sure we crack this out soon.

Has anyone been able to reproduce this issue locally? Curious to know if there are any log messages that happened around the crashing time?

@visumickey
I have rolled back to version 6.7.0, but this Crash still appears. Below is the details.

Googlers-only: Related to go/phenotype-deadlock

@visumickey I see same frames on the right side of stacktrace, but okay

Same issue here on iOS 10 (lowest supported).
Xcode 11 GM.

Same issue here but also impacting iOS 11 and 12 users.
Firebase SDK- '6.7.0'

´´´
Using Firebase (6.7.0)
Using FirebaseABTesting (3.1.0)
Using FirebaseAnalytics (6.1.1)
Using FirebaseAnalyticsInterop (1.4.0)
Using FirebaseAuth (6.2.3)
Using FirebaseAuthInterop (1.0.0)
Using FirebaseCore (6.2.1)
Using FirebaseCoreDiagnostics (1.0.1)
Using FirebaseCoreDiagnosticsInterop (1.0.0)
Using FirebaseFirestore (1.4.5)
Using FirebaseInstanceID (4.2.3)
Using FirebasePerformance (3.1.2)
Using FirebaseRemoteConfig (4.3.0)
Using FirebaseStorage (3.4.0)
´´´

If this crash is suddenly happening on versions 6.2.0 - 6.8.1, on Xcode 10 and 11 GM, and for people that haven't changed firebase version for 3 months, then it sounds like a BE issue like @patrickmarshall suggests?

Looking at the results from my updates to lock back to pod 'Firebase/Core', '~> 6.5.0' as mentioned early in this thread (which only went live last night to 3 apps), I can see that (in 1 app at least), the issue is still there now I reverted to the previous version.
Further, I now see that I have a previous build that was updated around 1 month ago has now got 1 single instance of this issue that is reporting as Sep 08 2019 08:06 (UTC) (iPhone 4s iOS 9.3.5).
As @ChristianVinterly & @patrickmarshall suggest, is this a backend change that has caused this?
All crashes I am seeing have been limited to iOS 9 / 10.

Looks like most of the crashes are on jailbroken devices though crashlytics dashboard shows 0% jailbroken devices but while checking individual crash details, All devices are shown jailbroken devices.

I just looked at my stats and, unlike @ashokbhakharios mine are not showing as Jailbroken (either at the dashboard or individually). All are showing Jailbroken: No.
So I guess that may not be linked.

Mine are also not Jailbroken

@ChristianVinterly is your crashes caused by updating pod versions? Or it just begin crash without your actions?

In our app, the crashes appeared yesterday after we released an update to TestFlight from Xcode 11 GM. The update did not change the Firebase SDKs, and the crash has not appeared on other versions of the app.

Wondering if this is a build tools issue - stemming from building with Xcode 11 instead of Xcode 10. Has anyone seen the issue with an Xcode 10 build?

I think the original post used Xcode Version 10.2.1.

My latest builds are with Xcode 11 Seed. But the one I have seen spring up from a build created 1 month ago was not the latest.

@paulb777 I am still using XCode 10.2.1 for distributing my app.

Here is more information for our crash,
Hope this will help Firebase SDK team here
Podfile:
pod 'Firebase/Core', '6.2.0'
pod 'Firebase/DynamicLinks', '6.2.0'
pod 'Firebase/Performance', '6.2.0'
pod 'Firebase/Messaging', '6.2.0'

Podfile.lock
  - Firebase/Core (6.2.0):
    - Firebase/CoreOnly
    - FirebaseAnalytics (= 6.0.1)
  - Firebase/CoreOnly (6.2.0):
    - FirebaseCore (= 6.0.2)
  - Firebase/DynamicLinks (6.2.0):
    - Firebase/CoreOnly
    - FirebaseDynamicLinks (~> 4.0.0)
  - Firebase/Messaging (6.2.0):
    - Firebase/CoreOnly
    - FirebaseMessaging (~> 4.0.2)
  - Firebase/Performance (6.2.0):
    - Firebase/CoreOnly
    - FirebasePerformance (~> 3.0.0)
  - FirebaseABTesting (3.0.0):
    - FirebaseCore (~> 6.0)
    - Protobuf (~> 3.5)
  - FirebaseAnalytics (6.0.1):
    - FirebaseCore (~> 6.0)
    - FirebaseInstanceID (~> 4.1)
    - GoogleAppMeasurement (= 6.0.1)
    - GoogleUtilities/AppDelegateSwizzler (~> 6.0)
    - GoogleUtilities/MethodSwizzler (~> 6.0)
    - GoogleUtilities/Network (~> 6.0)
    - "GoogleUtilities/NSData+zlib (~> 6.0)"
    - nanopb (~> 0.3)
  - FirebaseAnalyticsInterop (1.2.0)
  - FirebaseCore (6.0.2):
    - GoogleUtilities/Environment (~> 6.0)
    - GoogleUtilities/Logger (~> 6.0)
  - FirebaseDynamicLinks (4.0.0):
    - FirebaseAnalyticsInterop (~> 1.0)
    - FirebaseCore (~> 6.0)
  - FirebaseInstanceID (4.1.1):
    - FirebaseCore (~> 6.0)
    - GoogleUtilities/Environment (~> 6.0)
    - GoogleUtilities/UserDefaults (~> 6.0)
  - FirebaseMessaging (4.0.2):
    - FirebaseAnalyticsInterop (~> 1.1)
    - FirebaseCore (~> 6.0)
    - FirebaseInstanceID (~> 4.1)
    - GoogleUtilities/AppDelegateSwizzler (~> 6.2)
    - GoogleUtilities/Environment (~> 6.2)
    - GoogleUtilities/Reachability (~> 6.2)
    - GoogleUtilities/UserDefaults (~> 6.2)
    - Protobuf (~> 3.1)
  - FirebasePerformance (3.0.0):
    - FirebaseCore (~> 6.0)
    - FirebaseInstanceID (~> 4.0)
    - FirebaseRemoteConfig (~> 4.0)
    - GoogleToolboxForMac/Logger (~> 2.1)
    - "GoogleToolboxForMac/NSData+zlib (~> 2.1)"
    - GoogleUtilities/Environment (~> 6.0)
    - GoogleUtilities/ISASwizzler (~> 6.0)
    - GoogleUtilities/MethodSwizzler (~> 6.0)
    - GTMSessionFetcher/Core (~> 1.1)
    - Protobuf (~> 3.5)
  - FirebaseRemoteConfig (4.0.0):
    - FirebaseABTesting (~> 3.0)
    - FirebaseCore (~> 6.0)
    - FirebaseInstanceID (~> 4.0)
    - GoogleUtilities/Environment (~> 6.0)
    - "GoogleUtilities/NSData+zlib (~> 6.0)"
    - Protobuf (~> 3.5)

Fabric info:

Hi, we also face this issue.
for iOS10 users

Xcode 10.3
lock file

  - Firebase/Analytics (6.6.0):
    - Firebase/Core
  - Firebase/Core (6.6.0):
    - Firebase/CoreOnly
    - FirebaseAnalytics (= 6.1.0)
  - Firebase/CoreOnly (6.6.0):
    - FirebaseCore (= 6.2.0)
  - Firebase/Performance (6.6.0):
    - Firebase/CoreOnly
    - FirebasePerformance (~> 3.1.2)
  - FirebaseABTesting (3.0.0):
    - FirebaseCore (~> 6.0)
    - Protobuf (~> 3.5)
  - FirebaseAnalytics (6.1.0):
    - FirebaseCore (~> 6.2)
    - FirebaseInstanceID (~> 4.2)
    - GoogleAppMeasurement (= 6.1.0)
    - GoogleUtilities/AppDelegateSwizzler (~> 6.0)
    - GoogleUtilities/MethodSwizzler (~> 6.0)
    - GoogleUtilities/Network (~> 6.0)
    - "GoogleUtilities/NSData+zlib (~> 6.0)"
    - nanopb (~> 0.3)
  - FirebaseCore (6.2.0):
    - FirebaseCoreDiagnostics (~> 1.0)
    - FirebaseCoreDiagnosticsInterop (~> 1.0)
    - GoogleUtilities/Environment (~> 6.2)
    - GoogleUtilities/Logger (~> 6.2)
  - FirebaseCoreDiagnostics (1.0.1):
    - FirebaseCoreDiagnosticsInterop (~> 1.0)
    - GoogleDataTransportCCTSupport (~> 1.0)
    - GoogleUtilities/Environment (~> 6.2)
    - GoogleUtilities/Logger (~> 6.2)
  - FirebaseCoreDiagnosticsInterop (1.0.0)
  - FirebaseInstanceID (4.2.3):
    - FirebaseCore (~> 6.0)
    - GoogleUtilities/Environment (~> 6.0)
    - GoogleUtilities/UserDefaults (~> 6.0)
  - FirebasePerformance (3.1.2):
    - FirebaseCore (~> 6.2)
    - FirebaseInstanceID (~> 4.2)
    - FirebaseRemoteConfig (~> 4.2)
    - GoogleToolboxForMac/Logger (~> 2.1)
    - "GoogleToolboxForMac/NSData+zlib (~> 2.1)"
    - GoogleUtilities/Environment (~> 6.0)
    - GoogleUtilities/ISASwizzler (~> 6.0)
    - GoogleUtilities/MethodSwizzler (~> 6.0)
    - GTMSessionFetcher/Core (~> 1.1)
    - Protobuf (~> 3.5)
  - FirebaseRemoteConfig (4.2.1):
    - FirebaseABTesting (~> 3.0)
    - FirebaseCore (~> 6.1)
    - FirebaseInstanceID (~> 4.2)
    - GoogleUtilities/Environment (~> 6.0)
    - "GoogleUtilities/NSData+zlib (~> 6.0)"
    - Protobuf (~> 3.5)
...
 - Protobuf (3.9.0)
...

the crash stack is

and every crash log, it also has another thread call stack about CCTLogWriter
(not all of the crash log is the same stack.)

I'm not sure what relative between these two stack.
Hope can help this issue

@ChristianVinterly Yours is a Firestore/Protobuf issue, not related to Phenotype. Please file a separate issue.

Thanks a lot @patrickmarshall @Strate @willsbor for sharing the crash details. Thanks everyone for chiming:
Trying to get some details clarified:

Any instance of these crashes happening only on the latest build of the App (After updating to the latest version of Firebase)? (We are trying to ascertain if this is occurring only on the latest version. Our understanding based on the comments above is NO).
Have the crashes started showing only from Sep 13th? (Trying to narrow down the date range)
Has the volume of crashes slowed down or is that still in the same range? (Trying to make sure if this is not sporadic).
Apart from iOS 9 and iOS 10, do we have any insights on the kind of devices where this issue is more dominant? (Helps us to reproduce the issue).

Based on our understanding until now, we do not expect this to be an SDK issue. We are still working hard to figure out what could have caused this impact.
Please share your inputs on the questions above. That can help us great!

@visumickey

I've tried to downgrade Firebase dependencies to ~> 5.20.1, build new version to Test Flight and asked one of my users to test (I do not have iOS 10 device) - it still fails, with exactly same stack trace & error. Btw, previous versions of my app, which are uses exactly same version of Pod are not affected - I do not see any errors in Crashlytics from previous app builds.

Can't answer, because my app released later

Volume of crashes is increased by 100% right now (our new version in production for 2 days). Looks like all iOS9 & ios10 devices are affected.

Top of my affected devices are iPhone 5 & iPhone 5c

Now I check the theory that this is build issue. When I test on iPhone 5 & ios10 simulator via "Play" button in Xcode everything is fine (no crash). Now I want to archive and export .ipa-file to test on emulator.

Thanks @Strate. Can you share the podfile/podfile.lock after downgrading firebase to 5.20.1? May be we can try reproducing with that combination.

@visumickey

Podilfe.lock
PODS:
  - Bolts (1.9.0):
    - Bolts/AppLinks (= 1.9.0)
    - Bolts/Tasks (= 1.9.0)
  - Bolts/AppLinks (1.9.0):
    - Bolts/Tasks
  - Bolts/Tasks (1.9.0)
  - BoringSSL-GRPC (0.0.2):
    - BoringSSL-GRPC/Implementation (= 0.0.2)
    - BoringSSL-GRPC/Interface (= 0.0.2)
  - BoringSSL-GRPC/Implementation (0.0.2):
    - BoringSSL-GRPC/Interface (= 0.0.2)
  - BoringSSL-GRPC/Interface (0.0.2)
  - Crashlytics (3.12.0):
    - Fabric (~> 1.9.0)
  - Fabric (1.9.0)
  - FacebookSDK (4.38.0):
    - Bolts (~> 1.9)
    - FacebookSDK/CoreKit (= 4.38.0)
    - FacebookSDK/MarketingKit (= 4.38.0)
  - FacebookSDK/CoreKit (4.38.0):
    - Bolts (~> 1.9)
    - FBSDKCoreKit
  - FacebookSDK/MarketingKit (4.38.0):
    - Bolts (~> 1.9)
    - FacebookSDK/CoreKit
    - FBSDKMarketingKit
  - FBSDKCoreKit (4.38.1):
    - Bolts (~> 1.9)
  - FBSDKLoginKit (4.38.1):
    - FBSDKCoreKit
  - FBSDKMarketingKit (4.38.0):
    - FBSDKCoreKit
  - FBSDKShareKit (4.38.1):
    - FBSDKCoreKit
  - Firebase/Auth (5.20.2):
    - Firebase/CoreOnly
    - FirebaseAuth (= 5.4.2)
  - Firebase/Core (5.20.2):
    - Firebase/CoreOnly
    - FirebaseAnalytics (= 5.8.1)
  - Firebase/CoreOnly (5.20.2):
    - FirebaseCore (= 5.4.1)
  - Firebase/Database (5.20.2):
    - Firebase/CoreOnly
    - FirebaseDatabase (= 5.1.1)
  - Firebase/DynamicLinks (5.20.2):
    - Firebase/CoreOnly
    - FirebaseDynamicLinks (= 3.4.3)
  - Firebase/Firestore (5.20.2):
    - Firebase/CoreOnly
    - FirebaseFirestore (= 1.2.1)
  - Firebase/Messaging (5.20.2):
    - Firebase/CoreOnly
    - FirebaseMessaging (= 3.5.0)
  - Firebase/Performance (5.20.2):
    - Firebase/Core
    - FirebasePerformance (= 2.2.4)
  - Firebase/Storage (5.20.2):
    - Firebase/CoreOnly
    - FirebaseStorage (= 3.1.1)
  - FirebaseABTesting (2.0.0):
    - FirebaseCore (~> 5.0)
    - Protobuf (~> 3.5)
  - FirebaseAnalytics (5.8.1):
    - FirebaseCore (~> 5.4)
    - FirebaseInstanceID (~> 3.8)
    - GoogleAppMeasurement (= 5.8.1)
    - GoogleUtilities/AppDelegateSwizzler (~> 5.2)
    - GoogleUtilities/MethodSwizzler (~> 5.2)
    - GoogleUtilities/Network (~> 5.2)
    - "GoogleUtilities/NSData+zlib (~> 5.2)"
    - nanopb (~> 0.3)
  - FirebaseAnalyticsInterop (1.2.0)
  - FirebaseAuth (5.4.2):
    - FirebaseAuthInterop (~> 1.0)
    - FirebaseCore (~> 5.2)
    - GoogleUtilities/Environment (~> 5.2)
    - GTMSessionFetcher/Core (~> 1.1)
  - FirebaseAuthInterop (1.0.0)
  - FirebaseCore (5.4.1):
    - GoogleUtilities/Environment (~> 5.2)
    - GoogleUtilities/Logger (~> 5.2)
  - FirebaseDatabase (5.1.1):
    - FirebaseAuthInterop (~> 1.0)
    - FirebaseCore (~> 5.2)
    - leveldb-library (~> 1.18)
  - FirebaseDynamicLinks (3.4.3):
    - FirebaseAnalytics (~> 5.1)
    - FirebaseAnalyticsInterop (~> 1.0)
    - FirebaseCore (~> 5.2)
  - FirebaseFirestore (1.2.1):
    - FirebaseAuthInterop (~> 1.0)
    - FirebaseCore (~> 5.2)
    - FirebaseFirestore/abseil-cpp (= 1.2.1)
    - "gRPC-C++ (= 0.0.6)"
    - leveldb-library (~> 1.20)
    - nanopb (~> 0.3.901)
    - Protobuf (~> 3.1)
  - FirebaseFirestore/abseil-cpp (1.2.1):
    - FirebaseAuthInterop (~> 1.0)
    - FirebaseCore (~> 5.2)
    - "gRPC-C++ (= 0.0.6)"
    - leveldb-library (~> 1.20)
    - nanopb (~> 0.3.901)
    - Protobuf (~> 3.1)
  - FirebaseInstanceID (3.8.1):
    - FirebaseCore (~> 5.2)
    - GoogleUtilities/Environment (~> 5.2)
    - GoogleUtilities/UserDefaults (~> 5.2)
  - FirebaseMessaging (3.5.0):
    - FirebaseAnalyticsInterop (~> 1.1)
    - FirebaseCore (~> 5.2)
    - FirebaseInstanceID (~> 3.6)
    - GoogleUtilities/Environment (~> 5.3)
    - GoogleUtilities/Reachability (~> 5.3)
    - GoogleUtilities/UserDefaults (~> 5.3)
    - Protobuf (~> 3.1)
  - FirebasePerformance (2.2.4):
    - FirebaseAnalytics (~> 5.8)
    - FirebaseInstanceID (~> 3.8)
    - FirebaseRemoteConfig (~> 3.1)
    - GoogleToolboxForMac/Logger (~> 2.1)
    - "GoogleToolboxForMac/NSData+zlib (~> 2.1)"
    - GoogleUtilities/ISASwizzler (~> 5.2)
    - GoogleUtilities/MethodSwizzler (~> 5.2)
    - GTMSessionFetcher/Core (~> 1.1)
    - Protobuf (~> 3.5)
  - FirebaseRemoteConfig (3.1.0):
    - FirebaseABTesting (~> 2.0)
    - FirebaseAnalytics (~> 5.3)
    - FirebaseCore (~> 5.1)
    - FirebaseInstanceID (~> 3.3)
    - GoogleUtilities/Environment (~> 5.2)
    - "GoogleUtilities/NSData+zlib (~> 5.2)"
    - Protobuf (~> 3.5)
  - FirebaseStorage (3.1.1):
    - FirebaseAuthInterop (~> 1.0)
    - FirebaseCore (~> 5.2)
    - GTMSessionFetcher/Core (~> 1.1)
  - FLAnimatedImage (1.0.12)
  - GoogleAppMeasurement (5.8.1):
    - GoogleUtilities/AppDelegateSwizzler (~> 5.2)
    - GoogleUtilities/MethodSwizzler (~> 5.2)
    - GoogleUtilities/Network (~> 5.2)
    - "GoogleUtilities/NSData+zlib (~> 5.2)"
    - nanopb (~> 0.3)
  - GoogleSignIn (4.4.0):
    - "GoogleToolboxForMac/NSDictionary+URLArguments (~> 2.1)"
    - "GoogleToolboxForMac/NSString+URLArguments (~> 2.1)"
    - GTMSessionFetcher/Core (~> 1.1)
  - GoogleToolboxForMac/DebugUtils (2.2.1):
    - GoogleToolboxForMac/Defines (= 2.2.1)
  - GoogleToolboxForMac/Defines (2.2.1)
  - GoogleToolboxForMac/Logger (2.2.1):
    - GoogleToolboxForMac/Defines (= 2.2.1)
  - "GoogleToolboxForMac/NSData+zlib (2.2.1)":
    - GoogleToolboxForMac/Defines (= 2.2.1)
  - "GoogleToolboxForMac/NSDictionary+URLArguments (2.2.1)":
    - GoogleToolboxForMac/DebugUtils (= 2.2.1)
    - GoogleToolboxForMac/Defines (= 2.2.1)
    - "GoogleToolboxForMac/NSString+URLArguments (= 2.2.1)"
  - "GoogleToolboxForMac/NSString+URLArguments (2.2.1)"
  - GoogleUtilities/AppDelegateSwizzler (5.8.0):
    - GoogleUtilities/Environment
    - GoogleUtilities/Logger
    - GoogleUtilities/Network
  - GoogleUtilities/Environment (5.8.0)
  - GoogleUtilities/ISASwizzler (5.8.0)
  - GoogleUtilities/Logger (5.8.0):
    - GoogleUtilities/Environment
  - GoogleUtilities/MethodSwizzler (5.8.0):
    - GoogleUtilities/Logger
  - GoogleUtilities/Network (5.8.0):
    - GoogleUtilities/Logger
    - "GoogleUtilities/NSData+zlib"
    - GoogleUtilities/Reachability
  - "GoogleUtilities/NSData+zlib (5.8.0)"
  - GoogleUtilities/Reachability (5.8.0):
    - GoogleUtilities/Logger
  - GoogleUtilities/UserDefaults (5.8.0):
    - GoogleUtilities/Logger
  - "gRPC-C++ (0.0.6)":
    - "gRPC-C++/Implementation (= 0.0.6)"
    - "gRPC-C++/Interface (= 0.0.6)"
  - "gRPC-C++/Implementation (0.0.6)":
    - "gRPC-C++/Interface (= 0.0.6)"
    - gRPC-Core (= 1.17.0)
    - nanopb (~> 0.3)
  - "gRPC-C++/Interface (0.0.6)"
  - gRPC-Core (1.17.0):
    - gRPC-Core/Implementation (= 1.17.0)
    - gRPC-Core/Interface (= 1.17.0)
  - gRPC-Core/Implementation (1.17.0):
    - BoringSSL-GRPC (= 0.0.2)
    - gRPC-Core/Interface (= 1.17.0)
    - nanopb (~> 0.3)
  - gRPC-Core/Interface (1.17.0)
  - GTMSessionFetcher/Core (1.2.2)
  - leveldb-library (1.22)
  - MerryPhotoViewer (3.0.1):
    - NYTPhotoViewer
    - React
  - nanopb (0.3.901):
    - nanopb/decode (= 0.3.901)
    - nanopb/encode (= 0.3.901)
  - nanopb/decode (0.3.901)
  - nanopb/encode (0.3.901)
  - NYTPhotoViewer (2.0.0):
    - NYTPhotoViewer/AnimatedGifSupport (= 2.0.0)
    - NYTPhotoViewer/Core (= 2.0.0)
  - NYTPhotoViewer/AnimatedGifSupport (2.0.0):
    - FLAnimatedImage (~> 1.0.12)
    - NYTPhotoViewer/Core
  - NYTPhotoViewer/Core (2.0.0)
  - Protobuf (3.9.0)
  - QBImagePickerController (3.4.0)
  - React (0.59.9):
    - React/Core (= 0.59.9)
  - react-native-camera (2.2.2):
    - React
    - react-native-camera/RCT (= 2.2.2)
    - react-native-camera/RN (= 2.2.2)
  - react-native-camera/RCT (2.2.2):
    - React
  - react-native-camera/RN (2.2.2):
    - React
  - react-native-fast-image (6.1.1):
    - React
    - SDWebImage (~> 5.0)
  - react-native-image-resizer (1.0.0):
    - React
  - react-native-keep-awake (4.0.0):
    - React
  - react-native-orientation-locker (1.0.22):
    - React
  - react-native-video (4.4.4):
    - React
    - react-native-video/Video (= 4.4.4)
  - react-native-video/Video (4.4.4):
    - React
  - react-native-webview (5.12.0):
    - React
  - React/Core (0.59.9):
    - yoga (= 0.59.9.React)
  - React/fishhook (0.59.9)
  - React/RCTActionSheet (0.59.9):
    - React/Core
  - React/RCTAnimation (0.59.9):
    - React/Core
  - React/RCTBlob (0.59.9):
    - React/Core
  - React/RCTGeolocation (0.59.9):
    - React/Core
  - React/RCTImage (0.59.9):
    - React/Core
    - React/RCTNetwork
  - React/RCTLinkingIOS (0.59.9):
    - React/Core
  - React/RCTNetwork (0.59.9):
    - React/Core
  - React/RCTSettings (0.59.9):
    - React/Core
  - React/RCTText (0.59.9):
    - React/Core
  - React/RCTVibration (0.59.9):
    - React/Core
  - React/RCTWebSocket (0.59.9):
    - React/Core
    - React/fishhook
    - React/RCTBlob
  - rn-fetch-blob (0.10.6):
    - React/Core
  - RNAudio (4.3.0):
    - React
  - RNDeviceInfo (2.1.2):
    - React
  - RNFirebase (5.4.2):
    - Firebase/Core
    - React
  - RNFS (2.13.3):
    - React
  - RNGestureHandler (1.3.0):
    - React
  - RNGoogleSignin (1.0.2):
    - GoogleSignIn
    - React
  - RNImageCropPicker (0.21.3):
    - QBImagePickerController
    - React/Core
    - RSKImageCropper
  - RNSha256 (1.2.3):
    - React
  - RNSVG (8.0.11):
    - React
  - RNVectorIcons (6.6.0):
    - React
  - RSKImageCropper (2.2.3)
  - SDWebImage (5.0.6):
    - SDWebImage/Core (= 5.0.6)
  - SDWebImage/Core (5.0.6)
  - yoga (0.59.9.React)

DEPENDENCIES:
  - Crashlytics (~> 3.12.0)
  - Fabric (~> 1.9.0)
  - FacebookSDK (~> 4.38.0)
  - FBSDKCoreKit (~> 4.38.0)
  - FBSDKLoginKit (~> 4.38.0)
  - FBSDKShareKit (~> 4.38.0)
  - Firebase/Auth (~> 5.20.1)
  - Firebase/Core (~> 5.20.1)
  - Firebase/Database (~> 5.20.1)
  - Firebase/DynamicLinks (~> 5.20.1)
  - Firebase/Firestore (~> 5.20.1)
  - Firebase/Messaging (~> 5.20.1)
  - Firebase/Performance (~> 5.20.1)
  - Firebase/Storage (~> 5.20.1)
  - FirebaseAnalyticsInterop (= 1.2.0)
  - GoogleAppMeasurement (= 5.8.1)
  - GoogleSignIn (= 4.4.0)
  - "MerryPhotoViewer (from `../node_modules/@merryjs/photo-viewer`)"
  - NYTPhotoViewer (from `https://github.com/NYTimes/NYTPhotoViewer.git`, branch `master`)
  - react-native-camera (from `../node_modules/react-native-camera`)
  - react-native-fast-image (from `../node_modules/react-native-fast-image`)
  - react-native-image-resizer (from `../node_modules/react-native-image-resizer`)
  - react-native-keep-awake (from `../node_modules/react-native-keep-awake`)
  - react-native-orientation-locker (from `../node_modules/react-native-orientation-locker`)
  - react-native-video (from `../node_modules/react-native-video`)
  - react-native-webview (from `../node_modules/react-native-webview`)
  - React/Core (from `../node_modules/react-native`)
  - React/RCTActionSheet (from `../node_modules/react-native`)
  - React/RCTAnimation (from `../node_modules/react-native`)
  - React/RCTGeolocation (from `../node_modules/react-native`)
  - React/RCTImage (from `../node_modules/react-native`)
  - React/RCTLinkingIOS (from `../node_modules/react-native`)
  - React/RCTNetwork (from `../node_modules/react-native`)
  - React/RCTSettings (from `../node_modules/react-native`)
  - React/RCTText (from `../node_modules/react-native`)
  - React/RCTVibration (from `../node_modules/react-native`)
  - React/RCTWebSocket (from `../node_modules/react-native`)
  - rn-fetch-blob (from `../node_modules/rn-fetch-blob`)
  - RNAudio (from `../node_modules/react-native-audio`)
  - RNDeviceInfo (from `../node_modules/react-native-device-info`)
  - RNFirebase (from `../node_modules/react-native-firebase/ios`)
  - RNFS (from `../node_modules/react-native-fs`)
  - RNGestureHandler (from `../node_modules/react-native-gesture-handler`)
  - RNGoogleSignin (from `../node_modules/react-native-google-signin`)
  - RNImageCropPicker (from `../node_modules/react-native-image-crop-picker`)
  - RNSha256 (from `../node_modules/react-native-sha256`)
  - RNSVG (from `../node_modules/react-native-svg`)
  - RNVectorIcons (from `../node_modules/react-native-vector-icons`)
  - SDWebImage (= 5.0.6)
  - yoga (from `../node_modules/react-native/ReactCommon/yoga/yoga.podspec`)

SPEC REPOS:
  https://github.com/cocoapods/specs.git:
    - Bolts
    - BoringSSL-GRPC
    - Crashlytics
    - Fabric
    - FacebookSDK
    - FBSDKCoreKit
    - FBSDKLoginKit
    - FBSDKMarketingKit
    - FBSDKShareKit
    - Firebase
    - FirebaseABTesting
    - FirebaseAnalytics
    - FirebaseAnalyticsInterop
    - FirebaseAuth
    - FirebaseAuthInterop
    - FirebaseCore
    - FirebaseDatabase
    - FirebaseDynamicLinks
    - FirebaseFirestore
    - FirebaseInstanceID
    - FirebaseMessaging
    - FirebasePerformance
    - FirebaseRemoteConfig
    - FirebaseStorage
    - FLAnimatedImage
    - GoogleAppMeasurement
    - GoogleSignIn
    - GoogleToolboxForMac
    - GoogleUtilities
    - "gRPC-C++"
    - gRPC-Core
    - GTMSessionFetcher
    - leveldb-library
    - nanopb
    - Protobuf
    - QBImagePickerController
    - RSKImageCropper
    - SDWebImage

EXTERNAL SOURCES:
  MerryPhotoViewer:
    :path: "../node_modules/@merryjs/photo-viewer"
  NYTPhotoViewer:
    :branch: master
    :git: https://github.com/NYTimes/NYTPhotoViewer.git
  React:
    :path: "../node_modules/react-native"
  react-native-camera:
    :path: "../node_modules/react-native-camera"
  react-native-fast-image:
    :path: "../node_modules/react-native-fast-image"
  react-native-image-resizer:
    :path: "../node_modules/react-native-image-resizer"
  react-native-keep-awake:
    :path: "../node_modules/react-native-keep-awake"
  react-native-orientation-locker:
    :path: "../node_modules/react-native-orientation-locker"
  react-native-video:
    :path: "../node_modules/react-native-video"
  react-native-webview:
    :path: "../node_modules/react-native-webview"
  rn-fetch-blob:
    :path: "../node_modules/rn-fetch-blob"
  RNAudio:
    :path: "../node_modules/react-native-audio"
  RNDeviceInfo:
    :path: "../node_modules/react-native-device-info"
  RNFirebase:
    :path: "../node_modules/react-native-firebase/ios"
  RNFS:
    :path: "../node_modules/react-native-fs"
  RNGestureHandler:
    :path: "../node_modules/react-native-gesture-handler"
  RNGoogleSignin:
    :path: "../node_modules/react-native-google-signin"
  RNImageCropPicker:
    :path: "../node_modules/react-native-image-crop-picker"
  RNSha256:
    :path: "../node_modules/react-native-sha256"
  RNSVG:
    :path: "../node_modules/react-native-svg"
  RNVectorIcons:
    :path: "../node_modules/react-native-vector-icons"
  yoga:
    :path: "../node_modules/react-native/ReactCommon/yoga/yoga.podspec"

CHECKOUT OPTIONS:
  NYTPhotoViewer:
    :commit: 533a1fa40d0d4d518df737b76318715408050b74
    :git: https://github.com/NYTimes/NYTPhotoViewer.git

SPEC CHECKSUMS:
  Bolts: ac6567323eac61e203f6a9763667d0f711be34c8
  BoringSSL-GRPC: 2a230d9cd93e7ce39916044f645cebb31f37dde6
  Crashlytics: 07fb167b1694128c1c9a5a5cc319b0e9c3ca0933
  Fabric: f988e33c97f08930a413e08123064d2e5f68d655
  FacebookSDK: 73f54b8b94e09b05647cdef0af147f470cd3edc6
  FBSDKCoreKit: 8d47857400e2f5bdea697a80daff882e91c84ef6
  FBSDKLoginKit: 4621c690d9dd8628031a4791497062183ea34b0d
  FBSDKMarketingKit: e609f39d74ab273cf52e2f8b7e8829ed412b2827
  FBSDKShareKit: 6ffe22f0a0618eb7424d4104ab0ef3ce9643d42a
  Firebase: 0c8cf33f266410c61ab3e2265cfa412200351d9c
  FirebaseABTesting: 1f50b8d50f5e3469eea54e7463a7b7fe221d1f5e
  FirebaseAnalytics: ece1aa57a4f43c64d53a648b5a5e05151aae947b
  FirebaseAnalyticsInterop: efbe45c8385ec626e29f9525e5ebd38520dfb6c1
  FirebaseAuth: dd7bbf03a5aee0eafb3a1aee4d2812bd74bac890
  FirebaseAuthInterop: 0ffa57668be100582bb7643d4fcb7615496c41fc
  FirebaseCore: f1a9a8be1aee4bf71a2fc0f4096df6788bdfda61
  FirebaseDatabase: 2c15b0ea6f2c6eb5e57413f9d6340f1e50b81ae3
  FirebaseDynamicLinks: f7a8717e2c7ea652923882a2d60b0045d6fd99d5
  FirebaseFirestore: faca891c0f0d1d6c10c793473e2f6a29d75014b5
  FirebaseInstanceID: a122b0c258720cf250551bb2bedf48c699f80d90
  FirebaseMessaging: 4235f949ce1c4e827aeb19705ba5c53f9b85aa10
  FirebasePerformance: 25ecee2a260bcf398d7f32d6f4804438df953100
  FirebaseRemoteConfig: 7e11c65f0769c09bff6947997c209515058c5318
  FirebaseStorage: 6162ef4322502b818d9de0ec552f5226d283de43
  FLAnimatedImage: 4a0b56255d9b05f18b6dd7ee06871be5d3b89e31
  GoogleAppMeasurement: ffe513e90551844a739e7bcbb1d2aca1c28a4338
  GoogleSignIn: 7ff245e1a7b26d379099d3243a562f5747e23d39
  GoogleToolboxForMac: b3553629623a3b1bff17f555e736cd5a6d95ad55
  GoogleUtilities: 04fce34bcd5620c1ee76fb79172105c74a4df335
  "gRPC-C++": e76441995900ac90e9bd98644ab4733f12521edf
  gRPC-Core: 4028031ed2c5267cca0d846c876d8046b1ecb9b6
  GTMSessionFetcher: 61bb0f61a4cb560030f1222021178008a5727a23
  leveldb-library: 55d93ee664b4007aac644a782d11da33fba316f7
  MerryPhotoViewer: 76fd45056ab0a3746b4c57155e86227169330b9e
  nanopb: 2901f78ea1b7b4015c860c2fdd1ea2fee1a18d48
  NYTPhotoViewer: 34b8bd6bcc297466adec1668f9a01249d73c90e6
  Protobuf: 1097ca58584c8d9be81bfbf2c5ff5975648dd87a
  QBImagePickerController: d54cf93db6decf26baf6ed3472f336ef35cae022
  React: a86b92f00edbe1873a63e4a212c29b7a7ad5224f
  react-native-camera: 6d4d176ad6b10fda0aeeeb287ed2fc8b0194b118
  react-native-fast-image: fdfc612dba58fd73136cf5efdaeb8cfcad7f63b2
  react-native-image-resizer: aa1600566fd336a044daf9273dcec5033c1d41ca
  react-native-keep-awake: eba3137546b10003361b37c761f6c429b59814ae
  react-native-orientation-locker: ccb550d3b1019a7cbbce0f51faa605e9e6b523cf
  react-native-video: 25d5aebb3c9d7cdefe7a909306c7ab40be4a892c
  react-native-webview: 26d8993b090ca5d59eb9a9466dcb8291baa3223e
  rn-fetch-blob: 766f85cabd2992300dfa1be2bc9e4e258abc6f04
  RNAudio: cae2991f2dccb75163f260b60da8051717b959fa
  RNDeviceInfo: fd8296de6fca8b743cdc499b896f48e8a9f1faf5
  RNFirebase:<PHONE_NUMBER>14b0cef3225cc48709cabedd192d5e
  RNFS: c9bbde46b0d59619f8e7b735991c60e0f73d22c1
  RNGestureHandler: 5329a942fce3d41c68b84c2c2276ce06a696d8b0
  RNGoogleSignin: 361174d9a3090d295b06257162b560d8efc8a6ed
  RNImageCropPicker: 754299983d07c450aec0834c0efe0ed114131ff3
  RNSha256: 6fe8087682400f376fd78bd7d24222f0ec8ef968
  RNSVG: c3d27cf99f8484d3d8f8bb017b5438fd321267cf
  RNVectorIcons: 0bb4def82230be1333ddaeee9fcba45f0b288ed4
  RSKImageCropper: a446db0e8444a036b34f3c43db01b2373baa4b2a
  SDWebImage: 920f1a2ff1ca8296ad34f6e0510a1ef1d70ac965
  yoga: 03ff42a6f223fb88deeaed60249020d80c3091ee

PODFILE CHECKSUM: e72b28149c347933e09a4f6f1cec28ced98357ea

COCOAPODS: 1.7.5

Thanks @Strate. Will try reproducing with this combination.

@visumickey

Any instance of these crashes happening only on the latest build of the App (After updating to the latest version of Firebase)? (We are trying to ascertain if this is occurring only on the latest version. Our understanding based on the comments above is NO).

after the version which we face this issue, we release a new version. but we doesn't change the Firebase version. So we still see the crash report on crashlytics.
and we do not see any errors in Crashlytics from previous app builds.

Have the crashes started showing only from Sep 13th? (Trying to narrow down the date range)

or time zone is +8:00

Has the volume of crashes slowed down or is that still in the same range? (Trying to make sure if this is not sporadic).

I'm not sure.

Apart from iOS 9 and iOS 10, do we have any insights on the kind of devices where this issue is more dominant? (Helps us to reproduce the issue).

Thanks 🙏

@morganchen12 Sure, I can create another issue. But it has the exact same stack trace in Protobuf, even if call site from your framework is different.

@visumickey
Another information...
in Sep 12, we released a version 2.36.1, but it had a crash issue (not this). so we fixed it and released a version 2.36.2 in Sep 13. This version just fix a bug without changing Podfile / Podfile.lock.
the result is "2.36.1 didn't face this crash issue, but 2.36.2 has this crash."
(These two versions are separated by 1 to 2 days.)
I'm not sure what happened between the fix and Firebase. But that fix is modifying object creating timing. 🙏

Thanks for sharing the device information.
Given the device information we've seen so far, it seems that this is a 32-bit device only crash.  Has anyone seen this on a 64-bit device?
The crash occurs converting a stream to a double, so it could be an unaligned access error.  It's still totally a mystery to me why this just started occurring recently.

I've reproduced the crash on an iPhone 5c with the Firestore quickstart app. It crashes every time when building in release mode.

I found a workaround:
Update the GPBConvertInt64ToDouble function in . ./Pods/Protobuf/objectivec/GPBUtilities_PackagePrivate.h as follows with the volatile:
GPB_INLINE double GPBConvertInt64ToDouble(int64_t v) {
volatile union { double f; int64_t i; } u;
u.i = v;
return u.f;
}

Clean the workspace
Rebuild
Reapply if the pods are updated

Here's my best guess rationale:
There's an optimizer bug such that the compiler does not properly honor the alignment restrictions of an inline function that can result in an unaligned exception when accessing 64 bit data on a 32 bit processor.
I suspect the bug has been there a while, but has been exposed by a recent backend protocol buffers change.
We'll follow up with the Protocol Buffers team on a fix.

And here's a workaround that won't impact 64-bit performance:
GPB_INLINE double GPBConvertInt64ToDouble(int64_t v) {
#if __LP64__
  union { double f; int64_t i; } u;
#else
  volatile union { double f; int64_t i; } u;
#endif
  u.i = v;
  return u.f;
}

@paulb777 That is great that you managed to reproduce and resolve.
Are you releasing an urgent update? and if so, when do you expect? (Will it be an emergency release?) Or are we better to patch with this ourselves?
Thanks.

@neilmorton The patch timeline is still TBD. Since the crash is in a Firebase dependency and not in Firebase itself, we need to coordinate the fix and release with the Protobuf team. Also, we don't yet understand what made this bug all of a sudden occur starting last week.
It would also be helpful if others could reproduce with a release configuration build running on a 32 bit device and then verify the workaround.

@paulb777 Thanks for the clarification.
Unfortunately I haven't got anyone I can reach out to with a 32 bit device.
How confident are you in this fix? (Only asking before we start adding it manually!). Thanks.

I'm confident adding the volatile fixes the crash in the Firestore quickstart and it seems likely that it should fix any similar crashes.
However, given that we don't yet fully understand the root causes, there is still some uncertainty.
In summary, I would recommend that anyone using FirebaseFirestore or FirebasePerformance who cares about 32-bit device support to ship an update with the patch, ideally after verification if you can access a 32-bit device.
The patch should be a no-op for 64-bit devices and fix a likely crash for 32-bit devices.

@paulb777 is you release ipa have a bitcode option YES, I guess it is the bitcode option cause, I have the same issue, and I have not updated the SDK.

@fangyuxi did you release your app with a bitcode option?

@freezy7  YES

@fangyuxi I think it is caused by uploading ipa to App Connect and choosing rebuild with bicode. I think I can try not to select this option first, but it takes a certain amount of time to submit the review. I have not tried it yet.

@freezy7 可能不是bitcode的原因。还是别试了。

@paulb777 thank you for workaround. I confirm that this fixes crash on iPhone 5 device for my app.

@Strate Hello, Do I need to update my app or Firebase to fix this Crash ?

@fagyuxi I applied workaround manually and built new version of app to AppStore

We're continuing to investigate. The initial proposed Protobuf PR (see above) still causes an alignment exception.  The best known workaround is still to use the volatile change documented above.
Also, even though the initial bug report says Xcode 10 was used, we're only able to reproduce with Xcode 11 builds.  Is anyone else seeing the issue from an Xcode 10 build?

We're continuing to investigate. The initial proposed Protobuf PR (see above) still causes an alignment exception.  The best known workaround is still to use the volatile change documented above.
Also, even though the initial bug report says Xcode 10 was used, we're only able to reproduce with Xcode 11 builds.  Is anyone else seeing the issue from an Xcode 10 build?

@paulb777 I use xCode 10 right now. Can confirm crash & workaround.

Yes, we are getting this issue with Xcode 10.2.1 also.

We are getting same crash on iOS 11 and 12 with 64 Bit Devices.

Our production build that crashes is built with Xcode 10. We don't have any builds in production with Xcode 11 yet.

We are getting same crash on iOS 11 and 12 with 64 Bit Devices.

@Nishant-goibibo what specific device?  I didn't think arm64 had unaligned memory issues.  Or are you maybe build 32bit only and running that on arm64?

The protobuf fix is in progress at https://github.com/protocolbuffers/protobuf/pull/6678

hey everyone! when will be update?

Protobuf 3.9.2 has now been published to CocoaPods with the fix.
pod update to pick it up.

Thanks to everyone who contributed to this thread with backtraces and detailed crash information that helped us track this one down!

@paulb777 any timeline for a carthage update including the fix?

@datalogen Are you seeing the crash with a Carthage distribution?

@paulb777 Yes, we are seeing a similar crash with a Carthage distribution. We have quite a few customers running on older devices - iOS 9 and 10.
Crashed: com.google.firebase.firestore
0  DomainServices                 0x102f91c GPBCodedInputStreamReadDouble + 19
1  DomainServices                 0x102f915 GPBCodedInputStreamReadDouble + 12
2  DomainServices                 0x105b135 -[GPBMessage mergeFromCodedInputStream:extensionRegistry:] + 9112
3  DomainServices                 0x1030315 -[GPBCodedInputStream readMessage:extensionRegistry:] + 1406
4  DomainServices                 0x1036e33 ReadValue + 1148
5  DomainServices                 0x1036a93 GPBDictionaryReadEntry + 220
6  DomainServices                 0x103039d -[GPBCodedInputStream readMapEntry:extensionRegistry:field:parentMessage:] + 1542
7  DomainServices                 0x105b0ab -[GPBMessage mergeFromCodedInputStream:extensionRegistry:] + 8974
8  DomainServices                 0x1030315 -[GPBCodedInputStream readMessage:extensionRegistry:] + 1406
9  DomainServices                 0x105b2b3 -[GPBMessage mergeFromCodedInputStream:extensionRegistry:] + 9494
10 DomainServices                 0x105a7ab -[GPBMessage mergeFromData:extensionRegistry:] + 6670
11 DomainServices                 0x1057e99 -[GPBMessage initWithData:extensionRegistry:error:] + 768
12 DomainServices                 0x105a87f +[GPBMessage parseFromData:extensionRegistry:error:] + 6882
13 DomainServices                 0x105a849 +[GPBMessage parseFromData:error:] + 6828
14 DomainServices                 0xcb2669 firebase::firestore::local::LevelDbRemoteDocumentCache::DecodeMaybeDocument(absl::string_view, firebase::firestore::model::DocumentKey const&) + 200
15 DomainServices                 0xcb2fcf firebase::firestore::local::LevelDbRemoteDocumentCache::GetMatching(firebase::firestore::core::Query const&) + 370
16 DomainServices                 0xcb6e55 firebase::firestore::local::LocalDocumentsView::GetDocumentsMatchingCollectionQuery(firebase::firestore::core::Query const&) + 44
17 DomainServices                 0xcb65b1 firebase::firestore::local::LocalDocumentsView::GetDocumentsMatchingQuery(firebase::firestore::core::Query const&) + 56
18 DomainServices                 0xc6bd5d -[FSTLocalStore executeQuery:] + 115832
19 DomainServices                 0xc8a6ef -[FSTSyncEngine initializeViewAndComputeSnapshotForQueryData:] + 241162
20 DomainServices                 0xc89ffd -[FSTSyncEngine listenToQuery:] + 239384
21 DomainServices                 0xc1baef firebase::firestore::core::EventManager::AddQueryListener(std::__1::shared_ptrfirebase::firestore::core::QueryListener) + 754
22 DomainServices                 0xc44fdd std::__1::__function::__func<firebase::firestore::core::FirestoreClient::ListenToQuery(firebase::firestore::core::Query, firebase::firestore::core::ListenOptions, std::__1::shared_ptr<firebase::firestore::core::EventListenerfirebase::firestore::core::ViewSnapshot >&&)::$_11, std::__1::allocator<firebase::firestore::core::FirestoreClient::ListenToQuery(firebase::firestore::core::Query, firebase::firestore::core::ListenOptions, std::__1::shared_ptr<firebase::firestore::core::EventListenerfirebase::firestore::core::ViewSnapshot >&&)::$_11>, void ()>::operator()() + 21996
23 DomainServices                 0xbfa9bd firebase::firestore::util::AsyncQueue::ExecuteBlocking(std::__1::function<void ()> const&) + 112
24 DomainServices                 0xc1e3b3 firebase::firestore::util::internal::DispatchAsync(NSObject<OS_dispatch_queue>, std::__1::function<void ()>&&)::$_0::__invoke(void) + 474
25 libdispatch.dylib              0x1dff659d _dispatch_queue_serial_drain + 854
26 libdispatch.dylib              0x1dfecb71 _dispatch_queue_invoke + 886
27 libdispatch.dylib              0x1dff6a1f _dispatch_queue_override_invoke + 282
28 libdispatch.dylib              0x1dff81b5 _dispatch_root_queue_drain + 326
29 libdispatch.dylib              0x1dff800f _dispatch_worker_thread3 + 106
30 libsystem_pthread.dylib        0x1e19e87d _pthread_wqthread + 1040
31 libsystem_pthread.dylib        0x1e19e45c start_wqthread + 8

@paulb777 Debug builds are not showing the issue - release builds however are consistently crashing on my 32-bit device running iOS 9.3.5.

Thanks @datalogen.  The fix will be included in the Firebase 6.9.0 Carthage (and zip) release that is planned to go out early in the week.

Hello,
We have release our apps since september 27th and the problem doesn't seems to be appear anymore.
We just want to say thanks to @paulb777 @visumickey and other google team that help to fixed this issue.

Same issue here :'(
iOS 10 only, Firebase dependencies:
pod 'Firebase/Core', '= 6.8.1'
pod 'Firebase/Analytics', '= 6.8.1'
pod 'Firebase/Performance', '= 6.8.1'

Same thing here.


Phi-3 genai_config in .NET requiring to modification

While trying to load phi-3-mini-4k-instruct using ONNX Runtime Gen AI for .NET.
the load model method is failing saying not supported property:
"eos_token_id": [ 32000, 32001, 32007 ]
And the type property too, the default value for phi-3 is phi3.
I managed to get it work by removing the eos_token_id array and modifying type to phi instead of phi3
Maybe that needs to be mentioned somewhere.

My guess based on your description is that you're not using the correct library version from PyPI. Please use the pre-release version for runnning phi-3 using
# For CPU
pip install --pre onnxruntime-genai

# For CUDA
pip install --pre -i https://aiinfra.pkgs.visualstudio.com/PublicPackages/_packaging/onnxruntime-genai/pypi/simple/ onnxruntime-genai-cuda

The current pre-release version is 0.2.0-rc4.

Above tip worked for me! Was hitting the same issue when trying to run onnx runtime project with phi-3 model.
Agree it should be mentioned in the sample.

My guess based on your description is that you're not using the correct library version from nuget. Please use the pre-release version for phi-3: https://www.nuget.org/packages/Microsoft.ML.OnnxRuntimeGenAI/0.2.0-rc4
The current pre-release version is 0.2.0-rc4.

Updated 5 days! Alright, awesome, because I tried a lot but yeah now it makes sense, and it's working fine!
Thanks!


filter_jit static_argnames

I'd like to jit a function that has both an equinox.Module and a function as input. Here was my first attempt:
@functools.partial(jax.jit, static_argnames=['myfunction'])
def jit_function(mymodule: equinox.Module, myarray: jnp.ndarray, myfunction: typing.Callable) -> jnp.ndarray:

But am getting:
TypeError: Shapes must be 1D sequences of concrete values of integer type, got Traced<ShapedArray(int32[3])>with<DynamicJaxprTrace(level=0/1)>.

Then I tried changing to:
@functools.partial(equinox.filter_jit, static_argnames=['myfunction'])
def jit_function(mymodule: equinox.Module, myarray: jnp.ndarray, myfunction: typing.Callable) -> jnp.ndarray:

But am getting:
ValueError: `jitkwargs` cannot contain 'static_argnums', 'static_argnames' or 'donate_argnums'.

I'm not really sure how to proceed, if you have any insight I'd appreciate it!

Maybe this problem has nothing to do with equinox and is because my myarray is not a known size...

This issue looks to be something happening inside your JAX code. (And not something to do with Equinox.) Probably you're doing something like:
@jax.jit
def f(shape):
  return jax.numpy.zeros(shape)

Which doesn't work as JAX requires that all array shapes be known statically.
FWIW, if you're an Equinox user, then best practice is to just do
@eqx.filter_jit
def foo(...)

You shouldn't find yourself needing to manually specify what is traced and what is static. 99% of the time this is just determined by the type of each argument. (Arrays are traced, everything else is static.)

Ah, that is nice to not have to worry about defining static stuff with eqx.filter_jit. Thank you for the explanation! Have been enjoying using equinox.


Authorization header shouldn't be forwarded across redirects

Authorization headers are getting preserved even after redirects to a different server, which breaks if the target of the redirect isn't expecting Authorization (e.g. Amazon S3 throws a 400 error).
Ideally the behaviour would be the same as in curl or requesting the URL in a browser
For example:
var app = require('express')();

app.get('*', function(req, res){
  res.redirect('http://aws-lightbox.s3.amazonaws.com/source/jquery.fancybox.css');
});

app.listen(5678)

require('request')('http://foo:bar@localhost:5678/', function(err,resp){
  console.log('Request', resp.statusCode);
});

require('child_process').exec('curl -L -w "%{http_code}" -o /dev/null http://foo:bar@localhost:5678/', function(err, resp){
  console.log('Curl', resp)
});

Outputs:
Request 400
Curl 200

This is currently breaking NPM with links to GitHub private repo tarballs using basic auth, as they redirect to S3

This is still an issue for me, on Windows 7 and Ubuntu 14.04 LTS:
$ curl -i -L -k -H "Authorization: token <token>" -H "Accept: application/octet-stream" https://api.github.com/repos/<user>/<repo>/releases/assets/<id>
HTTP/1.1 302 Found
Server: GitHub.com
Date: Wed, 09 Sep 2015 20:11:17 GMT
Content-Type: text/html;charset=utf-8
Content-Length: 0
Status: 302 Found
X-RateLimit-Limit: 5000
X-RateLimit-Remaining: 4995
X-RateLimit-Reset:<PHONE_NUMBER>
location: https://s3.amazonaws.com/github-cloud/releases/<awsid>/<file-hash>?response-content-disposition=attachment; filename=<filename>&response-content-type=application/octet-stream&AWSAccessKeyId=<access-key-id>&Expires=<expires>&Signature=<signature>=
X-XSS-Protection: 1; mode=block
X-Frame-Options: deny
Content-Security-Policy: default-src 'none'
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: ETag, Link, X-GitHub-OTP, X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset, X-OAuth-Scopes, X-Accepted-OAuth-Scopes, X-Poll-Interval
Access-Control-Allow-Origin: *
X-GitHub-Request-Id: <github:request:id>
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
X-Content-Type-Options: nosniff
Vary: Accept-Encoding
X-Served-By: <served-by>

HTTP/1.1 400 Bad Request
x-amz-request-id: <amz-request-id>
x-amz-id-2: <amz-id-2/stuff>
Content-Type: application/xml
Transfer-Encoding: chunked
Date: Wed, 09 Sep 2015 20:11:18 GMT
Connection: close
Server: AmazonS3

<?xml version="1.0" encoding="UTF-8"?>
<Error>
  InvalidArgument
  <Message>
    Only one auth mechanism allowed;
    only the X-Amz-Algorithm query parameter,
    Signature query string parameter or the Authorization header should be specified
  </Message>
  <ArgumentName>Authorization</ArgumentName>
  <ArgumentValue>token </ArgumentValue>
  <RequestId></RequestId>
  <HostId></HostId>
</Error>

what's the trick? do I have to use wget?

Ah, but it does work in python requests. interesting.
>>> import requests
>>> headers = {"Authorization": "token <token>",
               "Accept": "application/octet-stream"}
>>> url = "https://api.github.com/repos/<user>/<repo>/releases/assets/<id>"
>>> s = requests.get(url=url, headers=headers)
>>> with open('<filename>', 'wb') as fp:
    fp.write(s.content)

@mikofski a better approach would be to create a new issue, and reference all other issues there instead of spamming the same content in all threads. GitHub puts back reference links to them.
I removed your posts in the other 3 issues.

@simov I am very sorry. Thanks for removing the other 3 issues. Should I open a new issue since this one is closed?

Yep, open another one, and link to the other issue from there.


Implemented Kover Maven Plugin

Resolves #51

Am I right that the parameters you've exposed as parameters are the ones that are conventionally have global single value and most often are changed?

Right, this was the basic idea, the single values that are most often same for all goals.


LS 2.2 not able to shut down successfully with kafka output

LS is not shutting down successfully with kafka output.  From the log,
{:timestamp=>"2016-03-23T03:29:06.229000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T03:31:59.894000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T03:34:29.099000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T03:35:22.879000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T03:43:54.882000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T03:44:34.726000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T03:51:00.526000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T03:53:47.678000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T03:54:49.860000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T03:55:58.732000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T03:57:34.653000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T03:58:49.865000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T04:01:06.229000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T04:02:39.863000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T04:05:05.546000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T04:07:54.866000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T04:08:44.868000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T04:09:49.334000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T04:11:32.503000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T04:14:06.457000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T04:15:59.870000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T04:22:56.624000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T04:24:54.854000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T04:29:59.857000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T04:32:03.416000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T04:34:59.792000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T04:37:27.440000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}
{:timestamp=>"2016-03-23T04:42:01.739000+0000", :message=>"The shutdown process appears to be stalled due to busy or blocked plugins. Check the logs for more information.", :level=>:error}

No other error message is logged.
Here is the config file.
input {
  file {
    type => "JFT"
    path => [ "/var/log/*.log" ]
    exclude => [ "*.gz", "*.gzip" , "*.bzip" , "*.bzip2" ]
    add_field => ["component", "Messenger" ]
    start_position => "end"
  }
}

output {
    kafka {
	       topic_id => "topic_id"
	       retry_backoff_ms => 1000
	       bootstrap_servers => "host:port"
	}
}

+1 Reproducible on 2.3.3.

generator -> kafka output
run pipeline with events going to kafka
shutdown kafka broker
attempt to shutdown kafka, it will report that it cannot shutdown due to stalled plugins
After 10+mins, still the same.

During this time, it repeatedly writes these warn messages to the log file with inflight count = 0:
{:timestamp=>"2016-07-04T01:45:20.595000-0400", :message=>#<LogStash::PipelineReporter::Snapshot:0x11a128c @data={:events_filtered=>96025, :events_consumed=>96025, :worker_count=>2, :inflight_count=>0, :worker_states=>[{:status=>"dead", :alive=>false, :index=>0, :inflight_count=>0}, {:status=>"dead", :alive=>false, :index=>1, :inflight_count=>0}], :output_info=>[{:type=>"kafka", :config=>{"codec"=>"plain", "topic_id"=>"test", "__ALLOW_ENV__"=>false}, :is_multi_worker=>false, :events_received=>96025, :workers=><Java::JavaUtilConcurrent::CopyOnWriteArrayList:1762476520 [<LogStash::Outputs::Kafka codec=><LogStash::Codecs::Plain charset=>"UTF-8">, topic_id=>"test", workers=>1, bootstrap_servers=>"localhost:9092", key_serializer=>"org.apache.kafka.common.serialization.StringSerializer", value_serializer=>"org.apache.kafka.common.serialization.StringSerializer", acks=>"1", buffer_memory=>33554432, compression_type=>"none", retries=>0, batch_size=>16384, linger_ms=>0, max_request_size=>1048576, receive_buffer_bytes=>32768, send_buffer_bytes=>131072, timeout_ms=>30000, block_on_buffer_full=>true, metadata_fetch_timeout_ms=>60000, metadata_max_age_ms=>300000, reconnect_backoff_ms=>10, retry_backoff_ms=>100>]>, :busy_workers=>1}, {:type=>"stdout", :config=>{"codec"=>"rubydebug", "__ALLOW_ENV__"=>false}, :is_multi_worker=>false, :events_received=>96025, :workers=><Java::JavaUtilConcurrent::CopyOnWriteArrayList:1552302076 [<LogStash::Outputs::Stdout codec=><LogStash::Codecs::RubyDebug metadata=>false>, workers=>1>]>, :busy_workers=>0}], :thread_info=>[], :stalling_threads_info=>[]}>, :level=>:warn}

While one can use the unsafe shutdown option, it seems like the plugin can handle this more gracefully.


Helper for wrapped errors

Sometime it's useful to catch some known errors and convert them to erroz-errors. Unfortunately those errorz-erros have the stacktrace of erroz-creation. It might be helpful to add an option to pass an original error when creating an erroz-error instance to append the original error.
Something like:

var ParseError = erroz({
  statusCode: 400,
  status: "fail",
  name: "ParseError",
  code: "parse-error",
  template "Could not parse %what"
});

try{
  JSON.parse("xaz--");
}
catch(err) {
   //pass original err as second argument (optional)
   errozErr = new ParseError({ what: "ever" }, err);

   console.log(errozErr.stack) //would equal err.stack
 }

Although it seems convenient it's also confusing as the stack is not pointing to the real "throw" . Maybe it's possible to merge the stacks or introduce a second originalStack attribute.

Mhmmm ... I'm not sure about this.
These should probably stay to different errors. The first error is an internal parse error that doesn't know the context, and the second one is the "public" error that is printed to the user. Imho it's ok that these are two distinct errors.

 But maybe we should leave it to application logic..

In any case the application needs to catch the error before it is passed to the global error handler, so I don't see the benefit here.

It's a few line less to write. And that's it. :tm:


feat: temp re-enable covid declaration flag

until the logic for the FE around unsubmitted/draft forms is agreed
TIS21-5401

The description and default value of the FEATURE_FORMR_PARTB_COVID_DECLARATION in README may need to be updated as well. https://github.com/Health-Education-England/tis-trainee-forms/blob/main/README.md?plain=1#L46
I am a bit confuse, other than the test, is this variable be used in any other place?

The variable is used in the front end to choose wether on not the covid declaration section is visiable when filling out a formR PartB form. it is sent through when forms are fetched as a feature flag variable
The value and description in the read-me can remain the same, it should have been changed in the previous PR but since its being reverted it can remain as is.

I see. 🌮  Thank you for the clarification about the usage. And I found how it works with FeatureConfigurationProperties from the historical commits.
Thank you for making sure the default value of FEATURE_FORMR_PARTB_COVID_DECLARATION in README is up-to-date. I was just wondering the variable description seems to be mixed up with the  APPLICATION_FILESTORE_ALWAYSSTORE.  I know it is an historical issue.


Appmenu / Global menu does not work on Kubuntu 14.04

When running atom (version 0.186.0) in KDE  (4.14.2 from Kubuntu 14.04) with the global menubar enabled, the menu is displayed, but does not work - clicking on any item does nothing, e.g. selecting 'Open File' from the 'File' menu does nothing.
Moreover, when I quit atom, the plasma-desktop (the main KDE desktop process) crashes.
This might indicate, that it is a bug in KDE, but I don't know how to figure this out.
Atom version: 0.186.0
OS: Kubuntu 14.04
KDE: 4.14.2

This is probably the same Issue as Issue #6255

It does sound like a duplicate. I'll close this one since the other has more information. Please subscribe there for updates.


[BEAM-11519] Adding PYPI_INSTALL_REQ role and SDK container support

Please add a meaningful description for your change here

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Choose reviewer(s) and mention them in a comment (R: @username).
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
[ ] Update CHANGES.md with noteworthy changes.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

Run Java PreCommit

Run Java PreCommit

R: @robertwb @chamikaramj
CC: @lostluck

R: @robertwb @chamikaramj
CC: @lostluck

@robertwb any other comments?

@robertwb any other comments?

@robertwb friendly ping

@robertwb friendly ping

Run Java_Examples_Dataflow PreCommit


Dear brother, every time I reboot, I re-download the python library,

My dear brother, my dear God,
Every time I restart hassos or AppDaemon
He would re-download it himself
Alpine Software Package
Python package
Can we add a button to the configuration options to decide whether to download these things automatically on the next reboot?
[Because the download speed is slow, half an hour, or the download fails, very troublesome, please]
Or some other way to keep him from downloading it again

`These log level also affects the log levels of the AppDaemon.
Option: system_packages
Allows you to specify additional Alpine packages to be installed to your AppDaemon setup (e.g., g++. make, ffmpeg).
Note: Adding many packages will result in a longer start-up time for the add-on.
Option: python_packages
Allows you to specify additional Python packages to be installed to your AppDaemon setup (e.g., PyMySQL. Requests, Pillow).
Note: Adding many packages will result in a longer start-up time for the add-on.
Option: init_commands
Customize your environment even more with the init_commands option. Add one or more shell commands to the list, and they will be executed every single time this add-on starts.`
Problem/Motivation
>    (Because I re-download the python library and Alpine package every time I reboot)
Expected behavior
>    (I would like to add a button switch to decide whether to re-download the software next time)
Actual behavior
>    (Nothing happened)
Steps to reproduce
>    (None)
Proposed changes
>    (None)

自己顶一下     Defend oneself

Yes this is intended and documented behavior.
../Frenck


Improve C++11 conformance

Eliminate unnecessary uses of new[]/delete[] that can be replaced with vector
Also start eliminating uses of plain-old delete that are not helpful
Eliminate namespaces that were just used to hide local templates or lambdas

Mark, I might back out all the range-based for work and do that separately. Something in there is causing incompatibility between gcc-4.9 that I build with on my Linux desktop and clang-7.3 that I use on my Mac laptop. Need to figure out the issue, so I think I'll resolve it in a separate PR.


WIX7009	The Directory symbol 'TARGETDIR' conflicts with a virtual symbol. Use the 'override' access modifier to override the virtual symbol or use a different Id to avoid the conflict. Referenced from wixstd.wixlib

Type of issue
Code doesn't work
Description
The given XML for Package.wxs does not work as the title indicates.
Page URL
https://learn.microsoft.com/en-us/dotnet/core/extensions/windows-service-with-installer?tabs=wix
Content source URL
https://github.com/dotnet/docs/blob/main/docs/core/extensions/windows-service-with-installer.md
Document Version Independent Id
83c4d805-1394-90b7-6def-cf809c33ae22
Article author
@IEvangelist
Metadata

ID: e044209a-0802-07c0-7518-208967a3ef02
Service: dotnet-fundamentals

I am also struggling with this error message.

Me too. Did anyone resolve this?


feat(core): support package path in client files

If you think this change is ok, I will update test files for it.

Should avoid that as we discussed


python312Packages.jupyter-server-ydoc: 1.0.1 -> 1.1.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python312Packages.jupyter-server-ydoc is: Jupyter-server extension integrating collaborative shared models
meta.homepage for python312Packages.jupyter-server-ydoc is: https://github.com/jupyterlab/jupyter-collaboration/tree/main/projects/jupyter-server-ydoc
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact
Checks done

built on NixOS

[!CAUTION]
A test defined in passthru.tests did not pass.

found 1.1.0 with grep in /nix/store/viq5wircjpq100iw8gnqnbs41dp7br0a-python3.12-jupyter-server-ydoc-1.1.0
found 1.1.0 in filename of file in /nix/store/viq5wircjpq100iw8gnqnbs41dp7br0a-python3.12-jupyter-server-ydoc-1.1.0

Rebuild report (if merged into master) (click to expand)

5 total rebuild path(s)

5 package rebuild(s)

First fifty rebuilds by attrpath

python311Packages.jupyter-collaboration
python311Packages.jupyter-server-ydoc
python312Packages.jupyter-collaboration
python312Packages.jupyter-server-ydoc

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/viq5wircjpq100iw8gnqnbs41dp7br0a-python3.12-jupyter-server-ydoc-1.1.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A python312Packages.jupyter-server-ydoc https://github.com/r-ryantm/nixpkgs/archive/1f449c0a059d46efb8abe3ceb00990e4d4405450.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/1f449c0a059d46efb8abe3ceb00990e4d4405450#python312Packages.jupyter-server-ydoc

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/viq5wircjpq100iw8gnqnbs41dp7br0a-python3.12-jupyter-server-ydoc-1.1.0
ls -la /nix/store/viq5wircjpq100iw8gnqnbs41dp7br0a-python3.12-jupyter-server-ydoc-1.1.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review

x86_64-linux

:white_check_mark: 8 packages built:

python311Packages.jupyter-collaboration
python311Packages.jupyter-collaboration.dist
python311Packages.jupyter-server-ydoc
python311Packages.jupyter-server-ydoc.dist
python312Packages.jupyter-collaboration
python312Packages.jupyter-collaboration.dist
python312Packages.jupyter-server-ydoc
python312Packages.jupyter-server-ydoc.dist

Maintainer pings
cc @GaetanLepage @natsukium @thomasjm for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review pr 365108

x86_64-linux

:white_check_mark: 8 packages built:

python311Packages.jupyter-collaboration
python311Packages.jupyter-collaboration.dist
python311Packages.jupyter-server-ydoc
python311Packages.jupyter-server-ydoc.dist
python312Packages.jupyter-collaboration
python312Packages.jupyter-collaboration.dist
python312Packages.jupyter-server-ydoc
python312Packages.jupyter-server-ydoc.dist

aarch64-linux

:white_check_mark: 8 packages built:

python311Packages.jupyter-collaboration
python311Packages.jupyter-collaboration.dist
python311Packages.jupyter-server-ydoc
python311Packages.jupyter-server-ydoc.dist
python312Packages.jupyter-collaboration
python312Packages.jupyter-collaboration.dist
python312Packages.jupyter-server-ydoc
python312Packages.jupyter-server-ydoc.dist

x86_64-darwin

:white_check_mark: 8 packages built:

python311Packages.jupyter-collaboration
python311Packages.jupyter-collaboration.dist
python311Packages.jupyter-server-ydoc
python311Packages.jupyter-server-ydoc.dist
python312Packages.jupyter-collaboration
python312Packages.jupyter-collaboration.dist
python312Packages.jupyter-server-ydoc
python312Packages.jupyter-server-ydoc.dist

aarch64-darwin

:white_check_mark: 8 packages built:

python311Packages.jupyter-collaboration
python311Packages.jupyter-collaboration.dist
python311Packages.jupyter-server-ydoc
python311Packages.jupyter-server-ydoc.dist
python312Packages.jupyter-collaboration
python312Packages.jupyter-collaboration.dist
python312Packages.jupyter-server-ydoc
python312Packages.jupyter-server-ydoc.dist


[CH] Make sure that all processors are cancelled before releasing global resources in native engine  and after yarn kill or driver shutdown command comes

Backend
CH (ClickHouse)
Bug description

Spark version
3.3
Spark configurations
AQE enabled
System information
No response
Relevant logs
2024/05/17 03:41:06,432 INFO [Executor task launch worker for task 15.0 in stage 1.0 (TID 67)] Executor: Finished task 15.0 in stage 1.0 (TID 67). 5183 bytes result sent to driver
2024/05/17 03:41:11,329 INFO [dispatcher-Executor] YarnCoarseGrainedExecutorBackend: Driver commanded a shutdown
2024/05/17 03:41:11,376 INFO [CoarseGrainedExecutorBackend-stop-executor] MemoryStore: MemoryStore cleared
2024/05/17 03:41:11,376 INFO [CoarseGrainedExecutorBackend-stop-executor] BlockManager: BlockManager stopped
2024-05-17 03:41:11.381 <Information> jni: start nativeOnTerminate
2024/05/17 03:41:12,445 INFO [shutdown-hook-0] JniLibLoader: Start unload library path /data17/hadoop/yarn/local/filecache/1281177/libch_240516.so
2024/05/17 03:41:12,446 INFO [shutdown-hook-0] JniLibLoader: verbosePath: /usr/hdp/<IP_ADDRESS>-78/hadoop/lib/native/libhadoop.so.1.0.0, libPath: /data17/hadoop/yarn/local/filecache/1281177/libch_240516.so
2024/05/17 03:41:12,446 INFO [shutdown-hook-0] JniLibLoader: Skip finalize because libhadoop.so.1.0.0 != libch_240516.so
2024/05/17 03:41:12,446 INFO [shutdown-hook-0] JniLibLoader: verbosePath: /data17/hadoop/yarn/local/filecache/1281177/libch_240516.so, libPath: /data17/hadoop/yarn/local/filecache/1281177/libch_240516.so
2024/05/17 03:41:12,446 INFO [shutdown-hook-0] JniLibLoader: Start finalize library file libch_240516.so
2024-05-17 03:41:12.446 <Information> jni: start JNI_OnUnload
2024/05/17 03:41:12,446 INFO [shutdown-hook-0] JniLibLoader: verbosePath: /data5/hadoop/yarn/local/usercache/xumingyong/appcache/application_1710462985812_773900/container_e57_1710462985812_773900_01_000004/tmp/liblz4-java-1735226946575805094.so, libPath: /data17/hadoop/yarn/local/filecache/1281177/libch_240516.so
2024/05/17 03:41:12,447 INFO [shutdown-hook-0] JniLibLoader: Skip finalize because liblz4-java-1735226946575805094.so != libch_240516.so
2024/05/17 03:41:12,456 INFO [shutdown-hook-0] ShutdownHookManager: Shutdown hook called

猜想：当driver发送shutdown command到executor时，executor执行ShutdownHookManager中注册过的hook函数，其中包括释放native engine中的全局资源。但是从上面的log看，此时native engine中，source算子还在执行，它会依赖已经被释放的全局资源(global thread pool), 从而造成crash.
TODO

LocalExecutor支持cancel功能，底层调用PullingPipelineExecutor::cancel。
实现gluten自定义processor的onCancel接口，在其中释放processor自身的资源。


Context menu for imgmaker commands

maybe not if it's too close to the commands limit

maybe all the meme generators commands could be a group, and that would give enough space?


Make a clone of Foundation Orbit

http://foundation.zurb.com/sites/docs/orbit.html
Roll your own JS into the component. Read here to learn how to make CSS animations happen properly in React: https://facebook.github.io/react/docs/animation.html

Following some of the new structures used for "sub-components", was thinking of having something like this for Orbit:
<Orbit>
  <Orbit.Slide>
    <Orbit.Image src="//placehold.it/900x450" alt="Orbit Image"/>
    <Orbit.Caption>Caption Text 1!</Orbit.Caption>
  </Orbit.Slide>
  <Orbit.Slide>
    <Orbit.Image src="//placehold.it/900x450" alt="Orbit Image"/>
    <Orbit.Caption>Caption Text 2!</Orbit.Caption>
  </Orbit.Slide>
  <Orbit.Slide>
    <Orbit.Image src="//placehold.it/900x450" alt="Orbit Image"/>
    <Orbit.Caption>Caption Text 3!</Orbit.Caption>
  </Orbit.Slide>
</Orbit>

Just an after thought, but does it make sense for us to re-create this component? I think most of our use cases for carousels is to typically use react-slick as it handles displaying multiple slides at a time.

Defers to Joel + Laura on leveraging third party vs recreating Foundation Orbit.

If no one else is working on this, I could start working on whipping it up once I finish testing the sticky component (#29) and adding some niceties to it like stickiness offset and bottom sticking (hopefully today or tomorrow).

I'm putting this together if anyone wants to mark this as in progress.

Given the fact that we've never made an attempt to do this, and given this comment:

Just an after thought, but does it make sense for us to re-create this component? I think most of our use cases for carousels is to typically use react-slick as it handles displaying multiple slides at a time.

I'm going to close this as "seemed like a good idea at the time."


Refactor to use typescript

Refactor to use typescript.


I think we should undefine the domain even if it is shutdown

@inercia @dmacvicar  any thoughts about this, i think we should destroy the domain if even it shutdown.

destroy in terraform means the resource should be gone. That is indeed undefine.
Now, resourceLibvirtDomainDelete already calls undefine. I tried the boot example and could not reproduce it. The domain was undefined.
Can you run destroy with TF_LOG=debug and show us why it stays there?

Yop i will update status tm with debug no pb

@dmacvicar  yop you are right, i think it was my mistake, i retry it now and the domain could get destroyed.
Thx and sorry :sunflower: closing

@MalloZup  can you please suggest the solution I am facing the same issue

I have a similar issue with storage pools - they're neither emptied no undefined is this expected?


frontend: bump @walletconnect versions to latest

Bump all @walletconnect dependencies to the newest versions:
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>Since the dependencies are transitive they should be updated together. There is no easy way to check for any breaking changes because there is not really something like a changelog (?).

tested with webdev real BB02M keystore and Wallet Connect to Uniswap, connection was established without any issues.

@NicolaLS please rebase

@NicolaLS please rebase

@thisconnect rebased

got the same lock file when I update. merging this...


Fix CI by downgrading OS image

Changes and Information
Please briefly list the changes (main added features, changed items, or corrected bugs) made:

Downgrade from ubuntu-latest (recently updated from 22.04 to 24.04) back to ubuntu-22.04
Remove PyQt6 dependency from py-epidata, as the version provided by image manylinux_2_28_x86_64 now breaks with python versions 3.8 and older.

If need be, add additional information and what the reviewer should look out for in particular:

While the epidata CI runs on ubuntu, parts use manylinux_2_28_x86_64 (AlmaLinux 9, not Debian based) via docker.
The PyPI pages of PyQt6 and PyQt6-sip suggest they should work with 3.8 and newer.
PyQt6-sip changed versions from the last successful Epidata-CI
 (v13.8) to the first failing Epidata-CI (v13.9). See line 139 in the respective CI.
We use PyQt as matplotlib backend (mpl_backend = QtAgg in epidata/download_config.conf), which is not tested by the CI, so it should be added back later.

Merge Request - Guideline Checklist
Please check our git workflow. Use the draft feature if the Pull Request is not yet ready to review.
Checks by code author

[x] Every addressed issue is linked (use the "Closes #ISSUE" keyword below)
[x] New code adheres to coding guidelines
[x] No large data files have been added (files should in sum not exceed 100 KB, avoid PDFs, Word docs, etc.)
[x] Tests are added for new functionality and a local test run was successful (with and without OpenMP)
[x] Appropriate documentation for new functionality has been added (Doxygen in the code and Markdown files if necessary)
[x] Proper attention to licenses, especially no new third-party software with conflicting license has been added
[ ] (For ABM development) Checked benchmark results and ran and posted a local test above from before and after development to ensure performance is monitored.

Checks by code reviewer(s)

[ ] Corresponding issue(s) is/are linked and addressed
[ ] Code is clean of development artifacts (no deactivated or commented code lines, no debugging printouts, etc.)
[ ] Appropriate unit tests have been added, CI passes, code coverage and performance is acceptable (did not decrease)
[ ] No large data files added in the whole history of commits(files should in sum not exceed 100 KB, avoid PDFs, Word docs, etc.)
[ ] On merge, add 2-5 lines with the changes (main added features, changed items, or corrected bugs) to the merge-commit-message. This can be taken from the briefly-list-the-changes above (best case) or the separate commit messages (worst case).

Again the CI fails due to indirect code coverage changes. I wonder if these are caused by un-mocked RNGs?


Change /health API components data from map to array

This PR should close #231 which changes the return value of /health API to make it more robust. The components field is changed from a map of components health status "componentName": {}, to an array of component health status:
"components": [
      {
          "name": "cmsd",
          "status": "ok",
          "last_update":<PHONE_NUMBER>
      },
      {
          "name": "federation",
          "status": "critical",
          "message": "Error advertising origin to federation",
          "last_update":<PHONE_NUMBER>
      }
]

In hope by doing this, we can eliminate errors from missing component health status at the front end.
This PR should be merged jointly with the PR for #232.

@haoming29 I don't understand this approach.
Doesn't @CannonLock simply need to check if the key exists?  It's not clear to me why an array is inherently better than a map...

I thought with more and more components added to the metric, if we want to display all them on dashboard, it's more flexible to use array instead of map so that Cannon can just iterate over available components and display them. With map, Cannon has to manually add the name of the new components each time and I thought that's not very efficient. I could be wrong though.

From: Brian P Bockelman @.>
Sent: Saturday, October 28, 2023 11:42:20 AM
To: PelicanPlatform/pelican @.>
Cc: HAOMING MENG @.>; Mention @.>
Subject: Re: [PelicanPlatform/pelican] Change /health API components data from map to array (PR #272)
@haoming29https://github.com/haoming29 I don't understand this approach.
Doesn't @CannonLockhttps://github.com/CannonLock simply need to check if the key exists? It's not clear to me why an array is inherently better than a map...
—
Reply to this email directly, view it on GitHubhttps://github.com/PelicanPlatform/pelican/pull/272#issuecomment-1783866695, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AJ3Z4KEXO37RZ2EOWSYC2G3YBUYWZAVCNFSM6AAAAAA6MSQMIGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTOOBTHA3DMNRZGU.
You are receiving this because you were mentioned.Message ID: @.***>