Crashed: tokio-runtime-worker for IOS

[c1982]

Hi folks,

I'm using Yaha v1.11.1 as GRPC client on Unity (v6000.1.5f1) We have been getting a lot of crashes on iOS lately.

Yaha Settings is:

                Http2Only = true,
                Http2AdaptiveWindow = true,
                PoolIdleTimeout = TimeSpan.FromMinutes(2),
                Http2KeepAliveWhileIdle = false,
                ConnectTimeout = TimeSpan.FromSeconds(12)

Trace is as follows.

0  libsystem_kernel.dylib         0xb1dc __pthread_kill + 8
1  libsystem_pthread.dylib        0x7c60 pthread_kill + 268
2  libsystem_c.dylib              0x772d0 abort + 124
3  libsystem_malloc.dylib         0x16d70 malloc_vreport + 892
4  libsystem_malloc.dylib         0x169e8 malloc_report + 64
5  libsystem_malloc.dylib         0x11594 ___BUG_IN_CLIENT_OF_LIBMALLOC_POINTER_BEING_FREED_WAS_NOT_ALLOCATED + 32
6  UnityFramework                 0x64b8454 core::ptr::drop_in_place$LT$tokio..runtime..task..core..Stage$LT$yaha_native..binding..yaha_request_begin..$u7b$$u7b$closure$u7d$$u7d$$GT$$GT$::hc3161cc6c3f9ec95 + 392640
7  UnityFramework                 0x64b8fb8 core::ptr::drop_in_place$LT$tokio..runtime..task..harness..poll_future..$u7b$$u7b$closure$u7d$$u7d$..Guard$LT$yaha_native..binding..yaha_request_begin..$u7b$$u7b$closure$u7d$$u7d$$C$alloc..sync..Arc$LT$tokio..runtime..scheduler..current_thread..Handle$GT$$GT$$GT$::h2cfad7e18483af5e + 395556
8  UnityFramework                 0x64bba54 tokio::runtime::task::harness::Harness$LT$T$C$S$GT$::poll::h7b92a6cd8b60b97c + 406464
9  UnityFramework                 0x6622610 tokio::runtime::scheduler::multi_thread::worker::Context::run_task::h7380ac8088d2521f + 596
10 UnityFramework                 0x662001c tokio::runtime::context::scoped::Scoped$LT$T$GT$::set::he6d0c6622b0923ca + 640
11 UnityFramework                 0x661c55c tokio::runtime::context::runtime::enter_runtime::hc727493226e38c0b + 516
12 UnityFramework                 0x662234c tokio::runtime::scheduler::multi_thread::worker::run::hbd73f82e5169ac5a + 104
13 UnityFramework                 0x662b47c tokio::runtime::task::core::Core$LT$T$C$S$GT$::poll::h5323d7e8693b7ffc + 3652
14 UnityFramework                 0x6600cf4 tokio::runtime::task::harness::Harness$LT$T$C$S$GT$::poll::h3911bee5cfacc862 + 7076
15 UnityFramework                 0x6613b9c tokio::runtime::blocking::pool::Inner::run::h7cb65a1b877c1f56 + 1604
16 UnityFramework                 0x6616424 std::sys::backtrace::__rust_begin_short_backtrace::ha559214fb74c3691 + 192
17 UnityFramework                 0x6616cf4 core::ops::function::FnOnce::call_once$u7b$$u7b$vtable.shim$u7d$$u7d$::h902e9e781817c27d + 1864
18 UnityFramework                 0x66ae4a8 std::sys::pal::unix::thread::Thread::new::thread_start::h45a7f62b02ec0fe0 + 395 (mod.rs:395)
19 libsystem_pthread.dylib        0x3344 _pthread_start + 136
20 libsystem_pthread.dylib        0xab8 thread_start + 8

[utkayd]

@c1982 did you ever resolve this? I'm having the same issue, pausing/resuming network activities upon the app being sent to the background and regained focus proved to be ineffective and the issue still persists.

[c1982]

Yes, The problem persists. The async network call on the C# side is probably closing prematurely. Tokio doesn't respect the TCP timeout mentioned above because we're constantly encountering double requests due to network issues.

[utkayd]

We've managed to pinpoint that the issue is stemming from application exits. We initially thought it was due to trying to carry out network operations in the background since 100% of the crashes are in the background but stopping network operations altogether wasn't fruitful.

Now we know the issue is due to non-graceful exits. Closing the app from the app switcher(going to the appswitcher and swiping up to kill the app) is causing the issue.

Using the handler's Dispose method and catching any probable ObjectDisposedException should result in a graceful exit. I'll update here once I verify the fix.