crash feedback version 0.3.2

[tomholub]

testflight_feedback 032.zip

[ivan-ushakov]

Crash happens here:

@objc func callJsCb(_ timer: Timer) {
    let callback = (timer.userInfo as! JSValue)
    callback.call(withArguments: nil)
    // todo - remove from timers by uuid, could cause possible memory leak
}

No ideas yet

[tomholub]

Does Thread 0 mean the main thread? Or not necessarily?

[ivan-ushakov]

Does Thread 0 mean the main thread? Or not necessarily?

Yes, main thread

[ivan-ushakov]

So maybe this is wrong to lock (JSC::JSLockHolder::JSLockHolder(JSC::VM&)) on main thread and some kind of assert happens

Thread 0 name:
Thread 0 Crashed:
0   libsystem_kernel.dylib              0x00000001b79dcf90 __psynch_cvwait + 8
1   libsystem_pthread.dylib             0x00000001f15cd254 _pthread_cond_wait + 1228 (pthread_cond.c:636)
2   JavaScriptCore                      0x000000018ca6b678 WTF::ParkingLot::parkConditionallyImpl(void const*, WTF::ScopedLambda<bool ()> const&, WTF::ScopedLambda<void ()> const&, WTF::TimeWithDynamicClockType const&) + 2968 (ThreadingPOSIX.cpp:582)
3   JavaScriptCore                      0x000000018ca5a2f4 WTF::LockAlgorithm<unsigned char, (unsigned char)1, (unsigned char)2, WTF::EmptyLockHooks<unsigned char> >::lockSlow(WTF::Atomic<unsigned char>&) + 228 (ParkingLot.h:82)
4   JavaScriptCore                      0x000000018c6a89f0 JSC::JSLock::lock(long) + 308 (Lock.h:66)
5   JavaScriptCore                      0x000000018c6a8504 JSC::JSLockHolder::JSLockHolder(JSC::VM&) + 48 (JSLock.cpp:97)
6   JavaScriptCore                      0x000000018b933858 -[JSValue callWithArguments:] + 76 (JSValue.mm:505)
7   FlowCrypt                           0x00000001046edc9c specialized CoreHost.callJsCb(_:) + 172 (CoreHost.swift:128)
8   FlowCrypt                           0x00000001046ecc28 CoreHost.callJsCb(_:) + 4 (<compiler-generated>:0)
9   FlowCrypt                           0x00000001046ecc28 @objc CoreHost.callJsCb(_:) + 40
10  Foundation                          0x00000001821f86ec __NSFireTimer + 104 (NSTimer.m:280)
11  CoreFoundation                      0x0000000180a52268 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 32 (CFRunLoop.c:1812)
12  CoreFoundation                      0x00000001809d6c40 __CFRunLoopDoTimer + 1076 (CFRunLoop.c:2420)
13  CoreFoundation                      0x00000001809d143c __CFRunLoopDoTimers + 328 (CFRunLoop.c:2580)
14  CoreFoundation                      0x00000001809afc58 __CFRunLoopRun + 1944 (CFRunLoop.c:3116)
15  CoreFoundation                      0x00000001809c33b8 CFRunLoopRunSpecific + 600 (CFRunLoop.c:3268)
16  GraphicsServices                    0x000000019c35338c GSEventRunModal + 164 (GSEvent.c:2200)
17  UIKitCore                           0x00000001833636a8 -[UIApplication _run] + 1100 (UIApplication.m:3493)
18  UIKitCore                           0x00000001830e27f4 UIApplicationMain + 2092 (UIApplication.m:5046)
19  FlowCrypt                           0x0000000104642338 closure #1 in  + 252 (main.swift:18)
20  FlowCrypt                           0x0000000104642364 specialized thunk for @callee_guaranteed () -> (@error @owned Error) + 20 (<compiler-generated>:0)
21  libswiftObjectiveC.dylib            0x00000001ae80aa20 autoreleasepool<A>(invoking:) + 64 (ObjectiveC.swift:172)
22  FlowCrypt                           0x0000000104642228 main + 48 (main.swift:12)
23  dyld                                0x00000001053c5a24 start + 520 (dyldMain.cpp:876)

[tomholub]

Is that something we do or something that JavaScriptCore does? I don't think it's us.

Unless we can run everything related to JavaScriptCore always on non-main thread? A dedicated one?

[ivan-ushakov]

Lock happens inside JavaScriptCore but maybe my assumption about lock on main thread is wrong. I need to investigate this.

[tomholub]

I think this could have been solved by synchronizing the calls. We'll see.