I have these showing in production here https://sentry.io/share/issue/ec9dbb43caf44eff917193994efa842a/ with no idea what is causing it at the moment.

Could you show the worker implementation causing this issue and the way this worker is created? Are you calling worker.terminate() somewhere in your code?

@darind
We're not using any custom workers in the app.
But there is only 1 plugin in our app that uses workers, nativescript-particle plugin. It has 2 workers.

I'm attaching the custom pack of the particle plugin that we use.

nativescript-particle-2.2.4.tgz.zip

We have kinvey-nativescript-sdk dep in our project which included a couple workers... I believe that's the only workers in our project, which we don't explicitly call.

Project package.json here and I don't recall any of these having workers, so it might only be Kinvey.

https://github.com/Kinvey/nativescript-sdk/blob/master/kinvey-nativescript-sdk.android.js

This is the crash I get during development

An uncaught Exception occurred on "W1: ./ffa39720cb93dc65b0d3.worker.js" thread.
Cannot find runtime for id:2

StackTrace:
	at com.tns.Runtime.runWorker(Native Method)
	at com.tns.Runtime.access$1500(Runtime.java:39)
	at com.tns.Runtime$WorkerThread$1.run(Runtime.java:472)
	at android.os.Handler.handleCallback(Handler.java:873)
	at android.os.Handler.dispatchMessage(Handler.java:99)
	at android.os.Looper.loop(Looper.java:193)
	at android.os.HandlerThread.run(HandlerThread.java:65)

and on the console

System.err: An uncaught Exception occurred on "W1: ./ffa39720cb93dc65b0d3.worker.js" thread.
System.err: Cannot find runtime for id:2
System.err: 
System.err: StackTrace:
System.err:     at com.tns.Runtime.runWorker(Native Method)
System.err:     at com.tns.Runtime.access$1500(Runtime.java:39)
System.err:     at com.tns.Runtime$WorkerThread$1.run(Runtime.java:472)
System.err:     at android.os.Handler.handleCallback(Handler.java:873)
System.err:     at android.os.Handler.dispatchMessage(Handler.java:99)
System.err:     at android.os.Looper.loop(Looper.java:193)
System.err:     at android.os.HandlerThread.run(HandlerThread.java:65)
System.err: com.tns.NativeScriptException: Cannot find runtime for id:2
System.err:     at com.tns.Runtime.passExceptionToJsNative(Native Method)
System.err:     at com.tns.Runtime.passUncaughtExceptionToJs(Runtime.java:82)
System.err:     at com.tns.NativeScriptUncaughtExceptionHandler.uncaughtException(NativeScriptUncaughtExceptionHandler.java:34)
System.err:     at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1068)
System.err:     at java.lang.ThreadGroup.uncaughtException(ThreadGroup.java:1063)
System.err:     at java.lang.Thread.dispatchUncaughtException(Thread.java:1955)

Also attaching logcat log
log.txt

I started getting this ever since I started using {N} 6.2

I've been using Workers probably longer and more often than most, and never seen this in Prod. However, ever since 6.2 enabled HMR by default, just for good measure I always pass the --no-hmr flag on release builds, and also block it in the webpack.config.js:

  const {
    // The 'appPath' and 'appResourcesPath' values are fetched from
    // the nsconfig.json configuration file.
    appPath = "src",
    appResourcesPath = "App_Resources",

    // You can provide the following flags when running 'tns run android|ios'
    aot, // --env.aot
    snapshot, // --env.snapshot,
    production, // --env.production
    uglify, // --env.uglify
    report, // --env.report
    sourceMap, // --env.sourceMap
    hiddenSourceMap, // --env.hiddenSourceMap
    // hmr, // --env.hmr,
    unitTesting, // --env.unitTesting
    verbose, // --env.verbose
    ci, // --env.ci
    snapshotInDocker, // --env.snapshotInDocker
    skipSnapshotTools, // --env.skipSnapshotTools
    compileSnapshot, // --env.compileSnapshot
  } = env;

  const hmr = false;

So seems like HMR is begin enabled by default without that flag, as I have both a permanent Worker (Analytics) and temporary Worker (background downloads). And I've never had this in Prod for either, despite having ~550K active installs right now and many other crashes of other types.

I'm gonna enable the --no-hmr in our release scripts now to see if that helps with prod release builds 👍

I've made a release with --no-hmr, will report here if I see that crash go away

@darind
There is only one plugin in our app that uses workers.
Nativescript-particle. It has 2 workers. Attaching the latest version that we use.
nativescript-particle-2.2.4.tgz.zip

It looks like the app reaches a point where it is trying to read from a file that does not exist.

Sorry, I forgot to leave an update here.
The issue still persists in production. Building with --no-hmr did not help.

I tried going back to an older version of dev-webpack (1.2.1), that did not help. The crash still occurs.

Every time this crash occurs, it is referring to a file that does not exist in the platforms folder.

Once it starts happening, the only way to stop it is to reinstall the app. This has been frustrating to work with.

@darind is anyone being assigned to this issue?

@shiv19, we are still unable to reproduce it locally. Can you share a project exhibiting this behavior?

@darind

Can you reach me over email please, I'll be happy to share code privately.
sp@shiv19.com

Can you try with the nativescript@next and nativescript-dev-webpack@next packages? There have been some fixes in those modules (scheduled for the 6.3 release) which should improve workers handling in HMR scenarios.

@darind
I can confirm that this crash does not occur in my project while using nativescript@next and nativescript-dev-webpack@next, moreover now the HMR is working even when there is worker in the project. Very happy with this.
Closing this issue now, thank you <3

Re-opened because the runWorker crash does eventually occur even in the @next build.

@darind,
Have sent you an email with instructions to re-create this crash, hope it helps.

Try disabling codeCache in your app/package.json: #1554

@darind
Turning off codeCache in app/package.json resolved the issue :)
Thanks a lot

@darind
This crash still exists in {N} 6.3

This method even has a TODO on it

// TODO: Pete: Why do I crash here with a JNI error (accessing bad jni)