Open shiv19 opened 4 years ago
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.
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
: https://github.com/NativeScript/android-runtime/issues/1554
@darind
Turning off codeCache in app/package.json
resolved the issue :)
Thanks a lot
@darind This crash still exists in {N} 6.3 https://github.com/NativeScript/android-runtime/blob/05a2a3d6fa62fea7f2b6bc4208cd61f50ec4a4e2/test-app/runtime/src/main/cpp/Runtime.cpp#L239
This method even has a TODO on it
// TODO: Pete: Why do I crash here with a JNI error (accessing bad jni)
nativescript: 6.2.2 tns-core-modules: 6.2.1 tns-android: 6.2.0 tns-ios: 6.2.0
I get this crash occasionally while developing with HMR. Now, this crash is even showing up in production. It's related to worker threads not loading as expected.