Do you see a lot of these chromecast exceptions? Or any other exceptions? That would be a good hint.
No, I don’t usually see them. I included them as they indicate start of instability/random issues. I’ll try to find out if the problem starts when rule is triggered or when rule is loaded, as I actually didn’t think about that previously.
I doubt it’s a general JS issue. Very often OOMs were related to connection issues in a bindings where old connections were not properly closed before new connections were opened. Was this the first time you encountered an OOM?
Let me try to look closer into the logs of previous incidents, and also try to reproduce the problem in a more systematic way. My system is usually very stable (and without OOM), but I agree that I need to verify which symptom is actually the first to start giving problems for others. JS might just have been the top of the iceberg if something else has already been misbehaving prior to that. Previously when I didn’t use JS at all, obviously I didn’t need memory for that, so some problems could have been hidden.
I have the same problem (“Java.lang.OutOfMemoryError: Java heap space”) which is described here.
Problem is not related to chromecast.
Thanks for the link, @Oliver2. From that other thread, @Giga522 provided an important clue about errors. A few hours ago I was not able to reproduce the problem, while it happened multiple times yesterday when I was working with the rules. Indeed the problem is very reproducible when having errors in the JS. I was able to get 100% CPU load just by introducing an error in the rule, and memory heap problems following that. I should be able to write a script or just a few reproduction steps tomorrow. I believe it’s now confirmed to be a problem with JS. When evidence is gathered, I’ll create an issue.
1 Like
I too was hit by this during my first JSS attempt 2 days ago. (Ubuntu x64, 3.2.0 release)
Since this was my first JS rule, I had many ‘saves’ which resulted in errors.
My rule has a cron trigger every 1s with a today= new Date as the first line, which I thought was to blame, and after adding a delete today after I was forced to restart OH memory usage stabilized.
Guess the delete is not needed. 
What is the best way to recover? A full OH restart or is it sufficient to restart the JSS add-on in Karaf?
1 Like
Seeing the same thing here, OH3.2 on Openhabian on Raspberry 4 4GB.
Experimenting with moving DSL rules to (file-based) JSScript and hence frequent saving of the rule, which at some point starts to freeze the systems, binding ceasing to function, etc. Restarting OH service from command line required to get system back to working again.
Wait… everybody who is reporting this issue is using file based scripts???
cause this sounds an awful lot like an issue that cropped up right after OH3 came out with using file based DSL rules
Right, that is exactly what Mark figured out, purposefully introducing an error caused the cpu to pin in a file based DSL rule
read more here in this thread and linked git issue that resulted in a fix but never really got to the root of issue
3 Likes
Hi Andrew,
I can reproduce this problem by testing rules which create an error during execution. However, my JS scripts are created in MainUI. I described this in this thread. I addressed this to the developer 5 days ago but did not get any feedback (no blaming, just providing some information)
do you mean you created an issue on github? If so please post a link to your issue so we can follow along. If not, if you mean you posted something on this forum then some of the developers don’t frequent the forum and creating an issue on github is the best way to make sure it gets in front of the right people.
Don’t worry… if it is a bug then others will have the same problem and eventually the problem will come to light
Good job Oliver, thanks for git link, will keep an eye on this as there seems to be one or two other recent threads seem similar
@laursen Can we mark this as solved now? ([jsscripting] Fix memory leak that crashes openHAB by florian-h05 · Pull Request #13824 · openhab/openhab-addons · GitHub)
Hi @florian-h05,
quite happy that I found out about your PR I pulled the latest Docker snapshot version of openHAB which I assume includes your fix. Unfortunately, the system still becomes unresponsive after too many changes in JS files.
The last logs were:
2022-12-08 21:36:27.684 [WARN ] [ab.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.openhab.core.io.monitor.internal.EventLogger@34fadc34' takes more than 5000ms.
2022-12-08 21:42:07.790 [WARN ] [ab.core.internal.events.EventHandler] - Dispatching event to subscriber 'org.openhab.core.io.monitor.internal.EventLogger@34fadc34' takes more than 5000ms.
After that I needed to perform a hard reset because the shell became unresponsive. Is there any chance you missed something? Or is my system’s behavior linked to another cause?
Your system‘s behaviour is quite strange to me, I don‘t think that I‘ve missed something. All tests that I did (on my PC, on my Raspberry) as well as the tests that @jlaur did show no heap increase which indicates that there is no memory leak left. Means Out of Memory shouldn‘t be caused by JS Scripting anymore.
I would suppose that your Docker openHAB did not pick-up the change, can you remove and install the JS Scripting addon again?
Can you please tell me your SNAPSHOT version (WebUI, About & Help)?
The last couple of weeks (month?) I have sometimes seen my system load go way up after saving a js file and openhab (not so much the system) becoming unresponsive. I didn’t have to do a hard reset and could (just) restart the docker comtainer. At this point I do not have logs. I am also on docker.
Perhasp good to note:
- I am on raspberry pi 4 4GB
- I am on the latest milestone
- I use docker
- I use js files
If you need me to run tests, let me know.
The fix is not in the latest milestone (M5), since I fixed it not before M5 was released.
It will be in the next milestone (M6), which will come (AFAIK) on Sunday.
Thanks, that helps!
Hi @florian-h05 , thanks for catching up.
My version in Web UI:
openHAB 3.4.0
Build #3209
Docker Image:
openhab/openhab:snapshot
Created: “2022-12-08T05:45:11.20894364Z”