Java error / full system freeze

Please paste text in code fences, not screenshots.

Is there a particular reason you’re running a 3.2 milestone? I don’t know if that’s related, but for stability it’s best to stay on production releases, unless you absolutely need something that has been updated in a milestone.

Thanks for your feedback! Tried to save this post by not adding all the logging. Was not aware of the code fences option. I have changed it. I’am now traveling, will check my exact OH version tonight @ home.

It looks like an out of memory error.
Some advises are given here: How to find the cause of a OutOfMemoryError in OH2?

I have OH version 3.1 (made an error in the version number

Thanks for sharing! I have red the post, it is all OH2 related and to my opinion quite generic for OH2.

What I don’t understand, i have a basic installation of OH3, no strange or unsupported bindings. In above logging it say’s that the cammera binding was the route cause. Based on old logging (which i saved last crash) it say’s that the speedtest binding was the rout caus. I have installed the system binding and I’ll monitor the physical memory. Now, 24h after the reboot 18.8% of the system memory is used.

I believe that’s why one of the recommendations in the linked post is to turn off bindings. The camera and speedtest bindings are just the ones that triggered the error–they aren’t necessarily the root causes. It could be that one of them (or some other binding) is spiking your memory usage to 99% without failing.

FYI, I don’t think that post is actually specific to OH2. It’s just that people often referred to OH2 in the same way we now talk about OH3.

@wborn, do these old instructions you gave for a generating a heap dump still apply, or is there a newer method for Debian Buster?

Yes you can still use dev:dump-create to create a heap dump. You issue that command on the Karaf Console, so it works regardless of what OS you use. :slight_smile:

1 Like

Thanks! I have downloaded the heapdump file from my system. The tool (Memory Analyser) doesn’t work on my mac :frowning: Do you know a tool which works on a mac?

In the meantime… increasing memory usage…

Java does not use normal memory, it uses the HEAP. If you upgrade to the latest Milestone the system info binding can track the heap size for you.

When your having an issue, the first thing you should try is upgrading IMHO as the reason there is a newer version is because issues have been found and fixed. There’s no point reporting an issue in 3.1 if it is already fixed.

Thanks, Do i install the latest mileston by selecting ‘main’ in Openhabian version menu (so main in stead openHab3)? Or is openhab3 the latest Milestone (in the menu Openhabian version)?

Menu 41 is used to switch between openHAB release trees.
Menu 01 selecting branch is used to switch between openhabian(-config) versions.

Menu 41 is what you would like to do get access to milestone bindings.

I think heap is equal to swap. Have connected some items and monitor it! Fingers crossed! thanks for helping!

They are very different things. The heap is found under the memory section and is only in the latest milestone as it is a new channel only just added.

Edit: when new channels are added you may need to delete and re add the thing to see the newer channels.

1 Like

Your last edit was quite important: THANKS!!! My heap say’s 84%, is this too much?

There is a minor bug that is fixed in the next milestone due any day now. The bug will mean the graph is higher up the Y axis then it should be if the current heap is less than the max allowed heap. Dont worry if that is another language to you, just update to the next milestone when out and the graph it creates will still be useful.

you want a graph that stays horizontal and does not grow over time. Here is mine from the past week.

The heap grows in size until what is called ‘garbage collection’ is done and then it drops back down and keeps repeating this cycle. If you can see the heap growing in size, then it will help you to find the cause quicker as you wont need to wait 3-5 days for the error to occur.


Thanks for the info. I will monitor it some day’s. Status untill tonight:

I can already see it increasing. The sharp drop was the heap resizing bigger, next version the drop won’t show on the graph.

Now you need to press the pause buttons to stop things running to see what stops the upwards trend. It can be a rule that has an issue but I doubt it will be a rule as the increase is constantly occurring so it will be some code that is running all the time and not just an occasional run.

1 Like

Yes! have stopped some bindings! will see soon what the effect is.

Have stopped all bindings. Below is the heap % of a day, per 8 hours the heap % goes up with 1%. Now i have started the MQTT broker with one import. Let’s see tomorrow what the effect is

1 Like

Graph looks good but that is to be expected when everything is disabled. When you do work out which binding it is, also disable any rules that use that binding as it may be a poorly written rule that has stopped because the trigger for the rule never occurs when you disable the binding.