search

xamarin / xamarin-macios

.NET for iOS, Mac Catalyst, macOS, and tvOS provide open-source bindings of the Apple SDKs for use with .NET managed languages such as C#
Other
2.43k stars 507 forks source link

Notification Callback crashes because collection is not locked #6704

Closed SOFSPEEL closed 4 years ago

SOFSPEEL commented 5 years ago

Crash report from AppCenter is:

Application Specific Information:
*** Terminating app due to uncaught exception 'SIGABRT', reason: 'Collection was modified; enumeration operation may not execute.'

Xamarin Exception Stack:
System.InvalidOperationException: **Collection was modified**; enumeration operation may not execute.
  at System.Collections.Generic.Dictionary`2+ValueCollection+Enumerator[TKey,TValue].MoveNext () <0x101176360 + 0x0010c> in <4fffe1dab0494c34a2a213216932b318#a1561c6d5fc7357f1676f8d092d865e6>:0
  at System.Net.Http.NSUrlSessionHandler.BackgroundNotificationCb (Foundation.NSNotification obj) <0x101e1f270 + 0x00087> in <0da8ced3e38d42039920e99e08ca9321#a1561c6d5fc7357f1676f8d092d865e6>:0
  at Foundation.InternalNSNotificationHandler.Post (Foundation.NSNotification s) <0x1013bdec0 + 0x0002f> in <b28d782d99614fe0b872da2da418b7b8#a1561c6d5fc7357f1676f8d092d865e6>:0
  at (wrapper managed-to-native) UIKit.UIApplication.UIApplicationMain(int,string[],intptr,intptr)
  at UIKit.UIApplication.Main (System.String[] args, System.IntPtr principal, System.IntPtr delegate) <0x10137d0c0 + 0x0002b> in <b28d782d99614fe0b872da2da418b7b8#a1561c6d5fc7357f1676f8d092d865e6>:0
  at UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) <0x10137d030 + 0x00043> in <b28d782d99614fe0b872da2da418b7b8#a1561c6d5fc7357f1676f8d092d865e6>:0
  at ACS.FundRaising.Application.Main (System.String[] args) <0x100e47f20 + 0x0004b> in <1463607bddc044fcbe415fbcafd2d18a#a1561c6d5fc7357f1676f8d092d865e6>:0

Note that I suspect the crash occurs because the following code in NsUrlSessionHandler is not locked:

https://github.com/xamarin/xamarin-macios/blob/master/src/Foundation/NSUrlSessionHandler.cs

So this:

void BackgroundNotificationCb (NSNotification obj)
{
    // we do not need to call the lock, we call cancel on the source, that will trigger all the needed code to 
    // clean the resources and such
    foreach (var r in inflightRequests.Values) {
        r.CompletionSource.TrySetCanceled ();
    }
}

Should be changed to (I think):

void BackgroundNotificationCb (NSNotification obj)
{
    lock (inflightRequestsLock) {
        foreach (var r in inflightRequests.Values) {
            r.CompletionSource.TrySetCanceled ();
        }
    }
}
OS Version:      iPhone OS 12.3.1 (16F203)
Report Version:  104

Exception Type:  SIGABRT
Exception Codes: #0 at 0x1879ae0dc
Crashed Thread:  0

Application Specific Information:
*** Terminating app due to uncaught exception 'SIGABRT', reason: 'Collection was modified; enumeration operation may not execute.'

Xamarin Exception Stack:
System.InvalidOperationException: Collection was modified; enumeration operation may not execute.
  at System.Collections.Generic.Dictionary`2+ValueCollection+Enumerator[TKey,TValue].MoveNext () <0x101176360 + 0x0010c> in <4fffe1dab0494c34a2a213216932b318#a1561c6d5fc7357f1676f8d092d865e6>:0
  at System.Net.Http.NSUrlSessionHandler.BackgroundNotificationCb (Foundation.NSNotification obj) <0x101e1f270 + 0x00087> in <0da8ced3e38d42039920e99e08ca9321#a1561c6d5fc7357f1676f8d092d865e6>:0
  at Foundation.InternalNSNotificationHandler.Post (Foundation.NSNotification s) <0x1013bdec0 + 0x0002f> in <b28d782d99614fe0b872da2da418b7b8#a1561c6d5fc7357f1676f8d092d865e6>:0
  at (wrapper managed-to-native) UIKit.UIApplication.UIApplicationMain(int,string[],intptr,intptr)
  at UIKit.UIApplication.Main (System.String[] args, System.IntPtr principal, System.IntPtr delegate) <0x10137d0c0 + 0x0002b> in <b28d782d99614fe0b872da2da418b7b8#a1561c6d5fc7357f1676f8d092d865e6>:0
  at UIKit.UIApplication.Main (System.String[] args, System.String principalClassName, System.String delegateClassName) <0x10137d030 + 0x00043> in <b28d782d99614fe0b872da2da418b7b8#a1561c6d5fc7357f1676f8d092d865e6>:0
  at ACS.FundRaising.Application.Main (System.String[] args) <0x100e47f20 + 0x0004b> in <1463607bddc044fcbe415fbcafd2d18a#a1561c6d5fc7357f1676f8d092d865e6>:0

Steps to Reproduce

  1. Have not been able to reproduce but our AppCenter crash reports relatively high incidence of the above issue.

Expected Behavior

Actual Behavior

Environment

=== Visual Studio Enterprise 2019 for Mac ===

Version 8.2.1 (build 19)
Installation UUID: 10188454-d1d9-4857-a988-1a86cdc38cea
    GTK+ 2.24.23 (Raleigh theme)
    Xamarin.Mac 5.14.0.85 (d16-2-fix-mac-updates / 86973979)

    Package version: 600000311

=== Mono Framework MDK ===

Runtime:
    Mono 6.0.0.311 (2019-02/494641b300c) (64-bit)
    Package version: 600000311

=== NuGet ===

Version: 5.1.0.6013

=== .NET Core ===

Runtime: /usr/local/share/dotnet/dotnet
Runtime Versions:
    2.2.4
    2.1.9
    2.1.8
    2.1.7
    2.1.2
    2.1.1
    2.0.5
SDK: /usr/local/share/dotnet/sdk/2.2.203/Sdks
SDK Versions:
    2.2.203
    2.1.505
    2.1.504
    2.1.503
    2.1.302
    2.1.301
    2.1.4
MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/6.0.0/lib/mono/msbuild/Current/bin/Sdks

=== Xamarin.Profiler ===

Version: 1.6.11
Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Updater ===

Version: 11

=== Xamarin.Android ===

Version: 9.4.0.51 (Visual Studio Enterprise)
Commit: xamarin-android/d16-2/9fa7775
Android SDK: /Users/SteveFeidelberg/Library/Android/sdk
    Supported Android versions:
        6.0 (API level 23)
        7.0 (API level 24)
        7.1 (API level 25)
        8.0 (API level 26)
        8.1 (API level 27)

SDK Tools Version: 26.1.1
SDK Platform Tools Version: 29.0.1
SDK Build Tools Version: 29.0.0 rc2

Build Information: 
Mono: mono/mono/2019-02@e6f5369c2d2
Java.Interop: xamarin/java.interop/d16-2@d64ada5
LibZipSharp: grendello/LibZipSharp/d16-2@caa0c74
LibZip: nih-at/libzip/rel-1-5-1@b95cf3f
ProGuard: xamarin/proguard/master@905836d
SQLite: xamarin/sqlite/3.27.1@8212a2d
Xamarin.Android Tools: xamarin/xamarin-android-tools/d16-2@6f6c969

=== Microsoft Mobile OpenJDK ===

Java SDK: /Users/SteveFeidelberg/Library/Developer/Xamarin/jdk/microsoft_dist_openjdk_8.0.25
1.8.0-25
Android Designer EPL code available here:
https://github.com/xamarin/AndroidDesigner.EPL

=== Android Device Manager ===

Version: 1.2.0.58
Hash: d03e3ea
Branch: remotes/origin/d16-2~1
Build date: 2019-07-16 17:37:14 UTC

=== Apple Developer Tools ===

Xcode 10.2.1 (14490.122)
Build 10E1001

=== Xamarin.Mac ===

Version: 5.14.0.110 (Visual Studio Enterprise)
Hash: a8bcecce
Branch: d16-2
Build date: 2019-06-28 07:31:43-0400

=== Xamarin.iOS ===

Version: 12.14.0.110 (Visual Studio Enterprise)
Hash: a8bcecce
Branch: d16-2
Build date: 2019-06-28 07:31:42-0400

=== Xamarin Designer ===

Version: 16.2.0.375
Hash: 357d38ef4
Branch: remotes/origin/d16-2
Build date: 2019-07-26 14:44:54 UTC

=== Xamarin Inspector ===

Version: 1.4.3
Hash: db27525
Branch: 1.4-release
Build date: Mon, 09 Jul 2018 21:20:18 GMT
Client compatibility: 1

=== Build Information ===

Release ID: 802010019
Git revision: c7aee29ba7d2a827dbfe4901e4ad7249ce7e5bc7
Build date: 2019-07-29 20:22:23+00
Build branch: release-8.2
Xamarin extensions: c990de17e8456ead7fce80aff9dab01df769b2fd

=== Operating System ===

Mac OS X 10.14.5
Darwin 18.6.0 Darwin Kernel Version 18.6.0
    Thu Apr 25 23:16:27 PDT 2019
    root:xnu-4903.261.4~2/RELEASE_X86_64 x86_64

=== Enabled user installed extensions ===

Team Foundation Version Control for TFS and Azure DevOps 0.4.4.5

Build Logs

Example Project (If Possible)

VS bug #960404

chamons commented 5 years ago

@mandel-macaque - Is this the known "fixed" issue or another can of worms?

chamons commented 5 years ago

This is not a designer bug - I fat fingered the category trying to hit ios and going too fast.

mandel-macaque commented 5 years ago

@chamons looks like a diff issue, but I'd be surprise this will happen. Do we have a code sample to reproduce it. The cancelation, the way I understand it is thread safe. I could add an extra check, but it would be nice to have a sample before adding more locks.

mandel-macaque commented 5 years ago

Also, we have https://github.com/xamarin/xamarin-macios/pull/6537 waiting to be landed.

SOFSPEEL commented 5 years ago

I also wanted to add that this is not an isolated incident, this has occurred with 20 different users over a two week period: image

SavikPavel commented 5 years ago

We're experiencing this issue in our production app as well

ramonesteban78 commented 5 years ago

Having this issue too in our Production app since our last update in Apple Store 17 days ago

rolfbjarne commented 5 years ago

There's not enough information here to determine if this is a threading issue or if the inflightRequests collection is being modified by the same thread when calling r.CompletionSource.TrySetCanceled.

I think this is a better attempt at a fix:

void BackgroundNotificationCb (NSNotification obj)
{
    foreach (var r in inflightRequests.Values.ToArray ()) {
        r.CompletionSource.TrySetCanceled ();
    }
}

@mandel-macaque since we don't have a test case, could you create a package with this fix so that it can be tested?

ideveloperaz commented 5 years ago

Hi! I have the exactly the same Crash report from AppCenter but I'm getting it when app not in memory (killed) and device locked .... and we have voip pushes that wakeup app... and it crashes in 99% ... so could be reproducible very well in my case

ideveloperaz commented 5 years ago

device has fingerprint lock .... when I open it after ReportInComingCall CallKit and I could see app few seconds ... then I have that crash and app restarts ... I could take video

ideveloperaz commented 5 years ago

Screen Shot 2019-08-22 at 10 35 23 PM

ideveloperaz commented 5 years ago

PS: when device has no pass code or no fingerprint ... it crashes in 50%. and only when app not in memory (i.e. killed)

ideveloperaz commented 5 years ago

also we having this crash a lot ... maybe related to this one ...

Screen Shot 2019-08-23 at 8 48 20 AM

ideveloperaz commented 5 years ago

@mandel-macaque what could we do?

thms-dwld commented 4 years ago

One of our production apps is having the same issue. Unfortunately, we have not been able to reproduce this error.

Though @ideveloperaz seems to be on to something here.

vs_about.txt collection_threading_crash.txt

mandel-macaque commented 4 years ago

Sorry, I was moving countries and could not reply fast enough. I will post a package (or a link to it) with the collection being locked to be tested. We already have the PR ready.

btctcn commented 4 years ago

My statistics concerning the issue. Let's force the fix please.

63520314-323ae000-c4fd-11e9-99ae-9ffe53eba0b9
mandel-macaque commented 4 years ago

I have provided a fix that will ensure that this does not longer happen. The proposed fix is in a PR that will generate a package, so that you can use it for testing and confirming the fix. There was not need for an extra lock, but for a temp collection to transverse. If approved, I will make sure that the fix is back ported two the next coming release.

Again, sorry for the delay, was out of work, is not a excuse but I want to give context for the delay :)

mandel-macaque commented 4 years ago

Packages can be found here:

ideveloperaz commented 4 years ago

Hello Everyone!

Since I'm the only one who could reproduce that crash here ... hereby I honestly confirm that that issue is fixed :-)

Good job @mandel-macaque !

ideveloperaz commented 4 years ago

But I'm having and was having different issue here with NSNotificationCenter.RemoveObserver I believe here is similar issue

Screen Shot 2019-08-30 at 8 29 27 AM

ideveloperaz commented 4 years ago

Screen Shot 2019-08-30 at 8 28 58 AM

mandel-macaque commented 4 years ago

@ideveloperaz I already have a PR in the flight for that too :) https://github.com/xamarin/xamarin-macios/pull/6537

ideveloperaz commented 4 years ago

Great @mandel-macaque :-) where we could find packages with all that issues altogether ? 😀 Today is really happy Friday ))

mandel-macaque commented 4 years ago

@ideveloperaz pkg is building, I made sure that you will get both issues fixed and I'll post them here for you to confirm :)

mandel-macaque commented 4 years ago

@ideveloperaz can you please take a look at the following .pkg and let me know if they are good for you:

ideveloperaz commented 4 years ago

Oh thank you a lot, Man! But I could do that during weekend, that issue with NSNotificationCenter not could be reproduced like prev one.On 30 Aug 2019 6:57 pm, Manuel de la Pena notifications@github.com wrote:@ideveloperaz can you please take a look at the following .pkg and let me know if they are good for you: xamarin.iosxamarin.mac

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

mandel-macaque commented 4 years ago

@ideveloperaz no worries, weekends are weekend, and you help is really welcomed :). I'll probably land this in master, but if you can do a +1 would be great.

ideveloperaz commented 4 years ago

Thank you a lot :-) I will do my best. But based on my monitoring of that issue, this could take some time to completely ensure that this issue fixed.On 30 Aug 2019 7:20 pm, Manuel de la Pena notifications@github.com wrote:@ideveloperaz no worries, weekends are weekend, and you help is really welcomed :). I'll probably land this in master, but if you can do a +1 would be great.

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

ghost commented 4 years ago

@ideveloperaz can you please take a look at the following .pkg and let me know if they are good for you:

When will the package with the fix available in the visual studio update? Are your linked package safe to install if we currently use 12.14.x?

ideveloperaz commented 4 years ago

@ideveloperaz can you please take a look at the following .pkg and let me know if they are good for you:

When will the package with the fix available in the visual studio update? Are your linked package safe to install if we currently use 12.14.x?

@StingrayFE, I could test .315 and it worked for me, regarding .317 I could never reproduce it myself only saw in crash logs so still keeping eyes on it, but could not see that issue as far

ideveloperaz commented 4 years ago

@ideveloperaz can you please take a look at the following .pkg and let me know if they are good for you:

When will the package with the fix available in the visual studio update? Are your linked package safe to install if we currently use 12.14.x?

I could not answer your question regarding when fixes will be available in VS because I dont work over fixes. But you could install that packages over 12.14.* ... was safe to install for me

ideveloperaz commented 4 years ago

Hi @mandel-macaque please kindly merge all fixes in that fix with #6762 #6916

why this fix (#6764) was not in current VS update?

may I have package with all that fixes in one place? or any ideas when #6764 will be in VS stable update?

divil5000 commented 4 years ago

This issue is still occurring for us. Let me be clear: our app is crashing, and our app is nowhere in the stack trace, because of this bug in Microsoft's code.

What is the status of the fix please?

rolfbjarne commented 4 years ago

@divil5000 which versions are you currently using? Can you get the version information from your IDE?

divil5000 commented 4 years ago

=== Visual Studio Professional 2019 for Mac ===

Version 8.3.11 (build 1) Installation UUID: fd515159-22b2-4783-b0b7-011a4038bba0 GTK+ 2.24.23 (Raleigh theme) Xamarin.Mac 5.16.1.24 (d16-3 / 08809f5b)

Package version: 604000208

=== Mono Framework MDK ===

Runtime: Mono 6.4.0.208 (2019-06/07c23f2ca43) (64-bit) Package version: 604000208

=== NuGet ===

Version: 5.3.0.6192

=== .NET Core SDK ===

SDK: /usr/local/share/dotnet/sdk/3.0.101/Sdks SDK Versions: 3.0.101 3.0.100 2.1.701 2.1.505 2.1.504 2.1.302 2.1.301 2.1.4 2.0.0 MSBuild SDKs: /Library/Frameworks/Mono.framework/Versions/6.4.0/lib/mono/msbuild/Current/bin/Sdks

=== .NET Core Runtime ===

Runtime: /usr/local/share/dotnet/dotnet Runtime Versions: 3.0.1 3.0.0 2.1.14 2.1.13 2.1.12 2.1.9 2.1.8 2.1.2 2.1.1 2.0.5 2.0.0

=== Xamarin.Profiler ===

Version: 1.6.12.26 Location: /Applications/Xamarin Profiler.app/Contents/MacOS/Xamarin Profiler

=== Updater ===

Version: 11

=== Xamarin.Android ===

Not Installed

=== Microsoft Mobile OpenJDK ===

Java SDK: Not Found

Android Designer EPL code available here: https://github.com/xamarin/AndroidDesigner.EPL

=== Android SDK Manager ===

Version: 1.4.0.65 Hash: c33b107 Branch: remotes/origin/d16-3 Build date: 2019-11-19 20:33:22 UTC

=== Android Device Manager ===

Version: 1.2.0.116 Hash: d2b2af0 Branch: remotes/origin/d16-3 Build date: 2019-11-19 20:33:42 UTC

=== Apple Developer Tools ===

Xcode 11.2.1 (15526.1) Build 11B53

=== Xamarin.Mac ===

Version: 6.6.0.12 (Visual Studio Professional) Hash: e3c2b406d Branch: xcode11.2 Build date: 2019-11-01 00:12:07-0400

=== Xamarin.iOS ===

Version: 13.6.0.12 (Visual Studio Professional) Hash: e3c2b406d Branch: xcode11.2 Build date: 2019-11-01 00:12:08-0400

=== Xamarin Designer ===

Version: 16.3.0.256 Hash: 8a223bfd7 Branch: remotes/origin/d16-3 Build date: 2019-11-01 21:02:02 UTC

=== Xamarin Inspector ===

Version: 1.4.3 Hash: db27525 Branch: 1.4-release Build date: Mon, 09 Jul 2018 21:20:18 GMT Client compatibility: 1

=== Build Information ===

Release ID: 803110001 Git revision: 6ee6ad2ec46ae5a08a1999ee4c815ac656a35b91 Build date: 2019-12-05 16:09:27+00 Build branch: release-8.3 Xamarin extensions: 56bd70ef2e327f71c615cfc29a47fd50685fadcb

=== Operating System ===

Mac OS X 10.14.4 Darwin 18.5.0 Darwin Kernel Version 18.5.0 Mon Mar 11 20:40:32 PDT 2019 root:xnu-4903.251.3~3/RELEASE_X86_64 x86_64

chamons commented 4 years ago

This was landed in xcode11 via

https://github.com/xamarin/xamarin-macios/pull/6880

and 13.6.0.12 is the current stable.

Could you please provide a stack trace at minimum and preferably a sample. This is the first report of regression, and I want to confirm that it is the same issue.

divil5000 commented 4 years ago

Here's our telemetry. I'm sure you're well aware that this isn't the sort of bug that can be easily reproduced on dev machines; we are seeing it hit our users in the field maybe 2 times per day, with tens of thousands of installations.

Version: 3.13.1.26610 MonoTouch: 13.6.0 iOS: 13.3 Hardware: iPhone12,1 System.InvalidOperationException: Collection was modified; enumeration operation may not execute. at System.Collections.Generic.Dictionary`2+ValueCollection+Enumerator[TKey,TValue].MoveNext () <0x1031c55d8 + 0x000c3> in <0e400f473a3e4716a829e46ba2f1f0d6#75df90ebb0348df8ab8974ad0820e7de>:0 at System.Net.Http.NSUrlSessionHandler.BackgroundNotificationCb (Foundation.NSNotification ) <0x1032c3878 + 0x0008b> in <e139e7c752b84c85bc1cc3eeae1725fa#75df90ebb0348df8ab8974ad0820e7de>:0 at Foundation.InternalNSNotificationHandler.Post (Foundation.NSNotification ) <0x103305e64 + 0x00017> in <e139e7c752b84c85bc1cc3eeae1725fa#75df90ebb0348df8ab8974ad0820e7de>:0 at (wrapper managed-to-native) UIKit.UIApplication.UIApplicationMain(int,string[],intptr,intptr) at UIKit.UIApplication.Main (System.String[] , System.IntPtr , System.IntPtr ) <0x1032e80b0 + 0x0003f> in <e139e7c752b84c85bc1cc3eeae1725fa#75df90ebb0348df8ab8974ad0820e7de>:0 at UIKit.UIApplication.Main (System.String[] , System.String , System.String ) <0x1032e8008 + 0x00053> in <e139e7c752b84c85bc1cc3eeae1725fa#75df90ebb0348df8ab8974ad0820e7de>:0 at Divelements.SkyDemon.Application.Main (System.String[] args) <0x102b0232c + 0x000bb> in <8bde7be67e974f7097924a2dcaf1f8a3#75df90ebb0348df8ab8974ad0820e7de>:0

mandel-macaque commented 4 years ago

@divil5000 until we find the root cause, please do the following in you application:

NSUrlSessionHandler handler = new NSUrlSessionHandler() { BypassBackgroundSessionCheck = true}

That will stop the crash.

Regarding your crash, is that the full stack trace> Can you provide a small sample of your code?

chamons commented 4 years ago

So we did some digging, and it turns out we did multiple passes at fixing this issue, one which made it rarer and one that fixed it completely. Due to release timing, the first fix is in stable today, and another is in d16-5, and upcoming release early next year.

As @mandel-macaque noted, you can work around this until that fix goes out.

Thanks for the report and feel free to reach out if you have any questions.

divil5000 commented 4 years ago

That is indeed a full stack trace. Thanks for the example line of code; can you explain what it does and its potential for side effects please? We are never explicitly instantiating NSUrlSessionHandler (we just use HttpClient) so it isn't clear where we should be using that suggested workaround.

divil5000 commented 4 years ago

This is presumably a related issue? Again, we see this thrown, crashing our app when our app isn't even in the stack trace, on a near-daily basis.

ObjectDisposedException at System.Threading.CancellationTokenSource.ThrowObjectDisposedException () <0x100fcfbcc + 0x00038> in <0e400f473a3e4716a829e46ba2f1f0d6#75df90ebb0348df8ab8974ad0820e7de>:0 at System.Threading.CancellationTokenSource.Cancel () <0x100fcf6e8 + 0x0001f> in <0e400f473a3e4716a829e46ba2f1f0d6#75df90ebb0348df8ab8974ad0820e7de>:0 at System.Net.Http.NSUrlSessionHandler+NSUrlSessionHandlerDelegate.DidCompleteWithError (Foundation.NSUrlSession , Foundation.NSUrlSessionTask , Foundation.NSError ) <0x1011a4474 + 0x0004f> in :0

That is the full stack trace.

mandel-macaque commented 4 years ago

@divil5000 The one-liner will remove the background notification that will cancel the request when you application goes to the background and the NSUrlSession was not created with a background configuration. This was added as a workaround to an issue that we found in the mono runtime threadpool in certain architectures in which the Treadpool will not recover correctly and the async callbacks would not work correctly when the application gets to the front.

You will only hit the issue of the tread pool in a small number of old devices, so with the one liner you will remove the crashes in most if not all modern devices and you might see issues in older ones. If I record correctly, 5S was the issue.

divil5000 commented 4 years ago

Thank you. It still isn't clear where that one-lines goes, though; I am not instantiating that class anywhere. Do I have to integrate it with my HttpClient calls somehow?

SavikPavel commented 4 years ago

We're experiencing exactly the same problems as @divil5000 does:

Screen Shot 2019-12-23 at 13 20 34 Screen Shot 2019-12-23 at 13 21 10

@divil5000, answering your question about where to put this one-liner, you should do it when instantiating HttpClient: _httpClient = new HttpClient(new NSUrlSessionHandler() { BypassBackgroundSessionCheck = true }); If you're creating your HttpClient in Core, you might want to create platform-specific HttpClientFactories or something like that

SavikPavel commented 4 years ago

By the way, I also have some more questions about this new BypassBackgroundSessionCheck flag. In our app, we have the problem with Http RefreshToken call. When the call is started and the app is backgrounded right away, the payload (that actually contains the token) is not attached to the Http response or is attached only partially. With BypassBackgroundSessionCheck flag set, it looks like the problem is gone, the content is always attached to the HTTP call. So, there are several different questions I want to ask:

  1. Why is that even happening?
  2. Is using BypassBackgroundSessionCheck the right way to fix it?
  3. Can I use BypassBackgroundSessionCheck flag only for some requests, not for all of them?
divil5000 commented 4 years ago

Thank you.

Unfortunately my Visual Studio for Mac reports being fully up-to-date and yet BypassBackgroundSessionCheck is NOT a member of NSUrlSessionHandler.

What on earth is going on? You've had this bug in your code for months with people running into it and yet it doesn't seem to be being fixed. Please note that we cannot use beta/non-stable software.

Sometimes I wonder if we are the only company using Xamarin for iOS in an app with tens of thousands of deployments being used every day by the public.

SavikPavel commented 4 years ago

@divil5000, you're not the only one, but it looks like there are not a lot of apps using Xamarin right now, that's true. I've just updated Xamarin iOS to the latest Stable version and the flag is not there for me as well. Looks like it's still only available in Beta right now

SavikPavel commented 4 years ago

I'm not sure if that's connected, but looks like it might be:

Screen Shot 2019-12-24 at 14 00 40

Unfortunately, I can't provide you the version of tools that we were using when creating this build, but I definitely know that it was right before updating to xCode 11, so that might be already fixed

Full crash log: crashlog.txt

SavikPavel commented 4 years ago

I can see that BypassBackgroundSessionCheck is included in the latest Xamarin.iOS release, thanks for that. But some questions are still open, can you please address them:

  1. Is ObjectDisposedException (https://github.com/xamarin/xamarin-macios/issues/6704#issuecomment-568434284) a related issue?
  2. Is NSUrlSessionHandler.SetResponse (https://github.com/xamarin/xamarin-macios/issues/6704#issuecomment-568725974) a related issue?
  3. Some questions about BypassBackgroundSession flag I've asked in this comment: https://github.com/xamarin/xamarin-macios/issues/6704#issuecomment-568436736