[jsscripting] Loading script files crashes openHAB #12577
Assignees
Labels
bug
An unexpected problem or unintended behavior of an add-on
Comments
|
@jpg0 - I've tried to provide some information for reproducing a stability issue with jsscripting I'm still having with the 3.3 milestone releases. I hope it will be possible to reproduce, otherwise please let me know of any additional details I can provide. |
|
I can't reproduce your failure (probably I have too much memory), but I can see an increasing use of heap memory due to rule-related objects not being unloaded properly:
This is caused by a bug in core which will be fixed by openhab/openhab-core#2897. |
|
@J-N-K - wow, that was fast! Thanks a lot! |
|
But there is at least one other memory leak. The I have no idea how that works, maybe @jpg0 knows. |
|
That wrapper is to try to synchronise access to a script engine. They don't support concurrent access. |
|
Yes, but someone still holds a reference to that after the script has been unloaded. That‘s not correct. |
|
Absolutely - I'll take a look at that. |
|
I have re-run this test after upgrading to 3.3M4 and the problem can still be reproduced. |
|
I took a look at this today. I did find a leak, which I have removed in #12725. |
|
I have re-run this test after upgrading to 3.3M6 (with #12725), and unfortunately the problem can still be reproduced. |
|
I can confirm that it is still there, 50 iterations of the script above result in the following:
So still the ScriptEngines are not garbage collected since someone holds a reference to them. |
|
@J-N-K any chance you could post the heap dump anywhere? |
|
I sent you an email with the link. |
|
Thanks for that. Looking at the dump has only confused me however.
|
|
I did see that 49 of them did not have a GC root, too. However, waiting an hour or manually performing GC from VisualVM did not remove them. I'll do another test and let the system add far more rules and see if the GC kicks in at some point. It's quite time consuming for me because MacOS is slow on detecting file changes (another issue I'm working on) and I need at least 15s between two rule changes. |
|
If I run even more (250), I get the following exception: I'm not sure if this is helpful, it just shows where the OOM first occurs. |
|
I've updated the description to reflect that this problem exists in the 3.3 release version also. |
|
@florian-h05 - I know it's too much to ask. But seeing your recent activity with moving jsscripting forward, I'm really hoping someone will be able to nail this at some point. I was hoping to spend Christmas last year migrating my rules to JS, but this is still is dream for me, since openHABian on a Raspberry Pi 3 will basically become unstable within minutes after starting working on scripts. 😢 |
|
@jlaur I have the hope that this issue is solved because I upgraded GraalJS in one of my latest PRs. As jpg0 stated back in June:
If the references really came from inside Graal, that might have been a bug which has been solved in a new version. |
|
It‘s only a question of the amount of reloads. My 16GB MacBook shows OOM after 260 reloads. How much memory do you have? And you‘ll see in VisualVM if the number of instances increases, even if it does not crash. |
|
My dev system has 32GB of RAM — that explains something here. I guess I would need many many reloads to experience OOM. |
|
@jlaur I will try this weekend to have at least a closer look at this. |
florian-h05
changed the title
|
@florian-h05 - I have now verified that this is still an issue in 3.4M5. |
|
First of all, I had to modify the JS file for reproducing the issuetest1.js: const { rules, triggers } = require('openhab');
rules.JSRule({
name: 'Reproduce jsscripting issue 1',
description: 'Reproduce jsscripting issue',
triggers: [triggers.ItemStateChangeTrigger('Issue12577', 'OFF', 'ON')],
execute: data => {
console.log('Test item triggered: 1');
}
});test2.js: const { rules, triggers } = require('openhab');
rules.JSRule({
name: 'Reproduce jsscripting issue 2',
description: 'Reproduce jsscripting issue',
triggers: [triggers.ItemStateChangeTrigger('Issue12577', 'ON', 'OFF')],
execute: data => {
console.log('Test item triggered: 2');
}
});After looking into this on my machine (Fedora 36, amd64, fixed heap site to 1G), I have noticed the following points:
Logs
UPDATE: |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is a follow-up bug report similar to #11952 which I was hoping would have been fixed by openhab/openhab-core#2681 and #12022, but the issue seems to remain in 3.4M5.
Expected Behavior
Loading a JS script from a file should not make the system unstable.
Current Behavior
After reloading a script file multiple times the system becomes slower and slower until it ultimately will become very unstable with timeouts.
Steps to Reproduce
Create this file somewhere as test1.sh:
And this one as test2.sh:
And finally, create this script as reproduce_issue_12577.sh:
Set execute permission:
Now run this script and wait a few minutes. For me, after running all 50 iterations, the last log items will look something like this:
After this point the system is no longer usable and a complete openHAB restart is needed. CPU usage of the java process is maxed out. Please note that from loading the script and until the rule was being added, almost a minute passed.
Context
This problem prevents migration from DSL rules to jsscripting, at least for users writing rules in files.
Your Environment
openHABian 1.7, openHAB 3.2-3.3.
The text was updated successfully, but these errors were encountered: