iOS app crash after permission request when I use a worker

[jamescodesthings]

Environment
Provide version numbers for the following components (information can be retrieved by running tns info in your project folder or by inspecting the package.json of the project):

• CLI: nativescript@7.0.9-rc.1
• Cross-platform modules: @nativescript/core@7.0.5
• Android Runtime: not tested
• iOS Runtime: @nativescript/ios@7.0.0
• Plugin(s): @nativescript/camera@5.0.0

Describe the bug
Error is:

EXC_BAD_ACCESS (code=1, address=0x107f35918)

iOS app crash after accepting any permissions, only happens with the worker I've got defined. Could be due to worker termination or mis-handling but any help is appreciated.

Crash Report: permissionreprod 25-09-2020, 16-53.txt

To Reproduce
See Repo: https://github.com/jamescodesthings/permission-reprod

Expected behavior
Nae crash.

Additional context
Ripped this out of a bigger, inherited application I'm updating to ns7. This was the smallest reproduction I could work out.

[jamescodesthings]

As a workaround I've just refactored out the worker on the local copy and it works as expected.

Are workers still supported and is there any better guidance on using them? I went from the link in the webpack.config.js template.

[NathanaelA]

Permissions asking should normally be done on the main thread and not a worker thread. Most OS's do not like visibility affecting items done on a background thread.

[jamescodesthings]

Sorry, to clarify, poorly titled; the permission request is being performed on the main thread (see repo), it's just the presence of the worker that causes the crash.

The reproduction is doing File work in the background using a worker, but requesting Camera permissions straight from the ui on the main thread.

The crash happens on whatever's calling back after the app resume caused by the permission request.

The only other detail I think could be related is that the worker is terminated when it's done with. So when the permission request happens the worker has been terminated.

[NathanaelA]

Hi, I can confirm the issue. We will be looking into the issue as time allow.

[jamescodesthings]

Cheers 😄

[darind]

@jamescodesthings, thanks for the detailed description and exact steps to reproduce the issue.

Can you try refactoring your workers logic so that you have a single long running worker which is always running and executing commands. This is better than spawning and terminating a worker every time you need to perform some operation.

For those interested, I narrowed down the issue to the following:

1. Start a new worker in which we require @nativescript/core. In turn this registers an NSNotificationObserver for the UIApplicationDidBecomeActiveNotification (and other notifications as well)
2. Terminate the worker
3. Use some code in your application which will raise the UIApplicationDidBecomeActiveNotification such as requesting camera permissions or something else.
4. Since we have two registered two subscribers for this notification (one form the main UI thread, and one from the worker thread), both subscribers are invoked.
5. The subscriber from the worker thread tries to use the V8 isolate which has already been disposed and the application crashes.

One way to prevent this would be to unregister all subscribers before terminating the worker thread. I don't think such functionality exists in the core modules and it would be great to provide. Maybe @NathanaelA or @NathanWalker could work on this to improve the modules behaviour in this aspect.

Until then I will create a fix in the runtime which will verify if the V8 isolate is alive inside callbacks before trying to use them. This way we will ensure that the callback won't be executed for disposed threads.

[jamescodesthings]

Hey @NathanaelA cheers for looking into the issue, cracking job.

I originally had a single long running worker and found that I'd get the occasional iOS app crash while the app was backgrounded for 30mn or so on an earlier version of the Nativescript 7 releases. I felt the two could be related after seeing the general guidelines docs here: https://docs.nativescript.org/core-concepts/multithreading-model#general-guidelines

In general when working with WebWorkers I was also used to terminating the worker after use to avoid similar restrictions in the browser.

It looks like you've pushed a commit that may address the issue? I can continue to refactor/debug in the mean-time if you'd like any further testing.

Cheers Again! 🎉

[NathanaelA]

Based on all my tests we solved that issue in 7.0.3.
Long running vs short lived - You can use either; but each start of a worker has a performance hit as it has to spin up a entirely new v8 engine effectively, so the best practice is typically to use a single worker that is long lived so that you just send a message to it and it does whatever you need without starting/stopping them.

If you run into issues with either short or long lived workers, please let us know! 😀

[jamescodesthings]

Cheers for clarifying. Appreciate it =]