android: Android worker crash since tns-android 6.3.0
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: 6.5.1
- Cross-platform modules: 6.5.0
- Android Runtime: 6.5.0 (also reproducable on 6.4.1)
- iOS Runtime (if applicable): -
- Plugin(s): nativescript-dev-webpack 1.5.1
Describe the bug When starting a worker script for the second time on an Androd 9 / 10 physical device, the worker thread throws an exception and most times, the app crashes as well.
Please note
- it seems to be reproducable only on a physical device with Android 9 or 10, it does not occur on any Android emulator and on device with older Android version
- everything was working as expected using tns-android 6.3.1 (issue occurs after upgrading to 6.4.1 or 6.5.0) --> update: 6.4.0 is the latest android runtime version without that bug!
- we reproduce this issue on our Google Pixel 3a (Android 10) and on our Nokia 5.1 (Android 9)
- the issue does not occur on our Nexus 4 (Android 5.1), Moto X Play (Android 7.1) and Moto Z Play (Android 8.0)
What we are doing in the demo app provided below On button tap we call this:
const WorkerScript = require("nativescript-worker-loader!./myworker");
const worker = new WorkerScript();
worker.onmessage = function(msg) {
if(msg.data.isWorkerLoaded) {
console.log("#### worker notify state 'loaded' -> start action...");
worker.postMessage({
action: "test"
});
} else if(msg.data.hasOwnProperty('success')) {
console.log("#### worker success");
worker.terminate();
alert("Worker success");
}
};
worker.onerror = function(e) {
console.log("#### worker onerror: ", e);
worker.terminate();
alert("Worker onerror");
};
And that’s the worker script:
//myworker.js
require("@nativescript/core/globals");
//notify main-thread about worker being loaded
global.postMessage({isWorkerLoaded: true});
global.onmessage = function(msg) {
if(msg.data.action === "test") {
setTimeout(function() {
global.postMessage({ success: true });
}, 3000);
}
};
To Reproduce 1.) Start the demo app provided below (on Android 9 or 10 physical device) 2.) Tap the button, wait some short time and you see the alert “Worker success” 3.) Tapping the button for a second time should also alert “Worker success”, but instead it crashes the app
4.)
tns platform remove android
tns platform add android@6.4.0
tns run android
5.) repeat steps 1-3 and you see that the app won’t crash anymore.
Expected behavior You should be able to start and terminate this worker script as often as you want, like it was working until tns-android 6.3.1
Sample project ns-worker-issue-android10.zip
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 2
- Comments: 42 (13 by maintainers)
Just a status update, I finally had a chance with the above demos I am able to cause a random crash on both the android.os.looper and it totally segfaulted on an emulator a couple of times. So I can duplicate this on Android 10 emulators with both samples… THANK YOU @felixkrautschuk for the samples!
It does look like something in the worker is getting corrupted; not sure what yet.
After some more discussions with my partners; we have agreed that this type of bug should be fixed on a higher priority basis, as crashing is a bad thing. So I’ll be looking into it shortly. Hopefully have some good news soon.
A fix was implemented for this in the
8.2.0-alpha.5so for those who want to give it a try please install the runtime using@alphato test , keep in mind the8.2 alphauses gradle 7 which requires Java 11 and also removedcompiledependency configuration (which was deprecated for a while now) in favour ofimplementation@alexander-mai i use the same technique and never had a crash either. However that being said i think we should get this fixed.
Hi, this is actually one of my higher priority bugs I’m looking into – now that we finally pushed out NS7 yesterday; the availability to track down some of these bugs should be a lot more available. 😃 I will be converting the two sample app to NS7 today and verifying that the issue wasn’t fixed by some of the other issues we fixed in NS7 and/or by the engine upgrade that also happened.
We are currently doing work on the runtime, I’ll try my best to get to this 😃
Sent from Yahoo Mail for iPhone
On Thursday, December 16, 2021, 12:32 PM, A92C @.***> wrote:
news? or as always everyone in silence?
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are on a team that was mentioned.Message ID: @.***>
Sorry for that 😄
When I run into a new issue, it is always the first step for me to create a new app project and check if it also occurs there and if not, I know that is must be a mistake from myself in my own project. But that’s not the case here 😉
fixed in 8.2
Hello @felixkrautschuk , I can’t see any battery issue. The only difference is the higher complexity of the worker to differentiate between the tasks and the assignment of the responses to the individual callers.
6.3.1 (and also 6.3.0) are later released than 6.4.0-2019-12-06-124802-03
It is no longer called
tns-android; everything is now in the @nativescript namespace. So@nativescript/androidis the runtime…If you want to manually try this engine with a older CLI; you can use
npm infoto get the download link (or download it from github releases) of the latest engine, then usetns platform add android --frameworkPath <tgz_file_downloaded>@NathanaelA Indeed, 6.4.0 is the latest working android runtime, not 6.3.1.
In the release notes, they only mentioned 6.4.1, that’s why I did not explicitly test 6.4.0.