-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gui memory issue #676
Comments
There was already a issue for this, just not marked for 2.60, #653 |
a ccgx running v2.57 and with a gui not using a lot of memory also encountered this:
The device can no longer leave the overview and show the pages. |
The latest Venus version has some counters / debug options and is already running at the customer its site. There are hundreds of svg's which have a width of 145px and various different heights. Seems like a svg with a property animation on height. In total 30MB or so, so that at least explains where the memory is going (and that is already fixed, since the cache for inline svg's is completely disabled now). It will now also exit on OOM, so next time it will hopefully occur during allocation of all these images, instead of a random different place (the check update in case). It remains interesting why the fork fails on low mem, since it doesn't seem to be on memory allocation, nor on mmap failure... page.status !== undefined is likely unrelated¸ since it occurs on v2.57 as well. |
Solved - closing |
The fork failure is caused by https://github.com/victronenergy/linux/blob/ccgx_b4.19.74/mm/util.c#L662 Note: that whole check got replaced in victronenergy/linux@8c7829b |
As reported here https://community.victronenergy.com/comments/55615/view.html and for earlier versions as well, the gui can run out of memory which make running a process, like reboot or check update fail:
"Resource error (fork failure): Cannot allocate memory"
Not being able to return from the overview to the pages seem to be caused by this:
I wouldn't be surprised if that is caused by the same reason, failing to allocate the page and hence pushing a undefined page on to the stack.
Why this setup runs out of memory is unknown at the moment, but it must have to do with user interaction or something otherwise we would have received lots of complaints about the gui getting stuck / ignoring commands.
The text was updated successfully, but these errors were encountered: