Two different Chrome OS devices appear to have a memory leak
Reported by
dgtboxva...@gmail.com,
Apr 18 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36 Platform: Asus Chromebox/Chromebit Steps to reproduce the problem: 1. Make a playlist of 3 video's/2 jpeg's and 2 websites (shown in webview), let each part play for 15-60 seconds and loop 2. Install this code on Chrome OS device and set device to run in kiosk mode with no restart. 3. After less than 3 days, Chrome OS device should restart by itself What is the expected behavior? At least for the Chromebox, one would expect it to be able to run for weeks playing through a list of video's/ photo's and websites. But both Chromebox and chromebit restart in less than 3 days. What went wrong? The case is very simple: I am building a Digital Signage application that will run in kiosk mode on a Chrome OS device. This application has to download some video's and pictures, save them to the local filesystem and then loop through them. That's it! The code is very simple. I keep an array of objects with url of the local file and the duration (how long it should be displayed as a scene in the playlist). At every new scene, the html is rendered (video tag for video, img tag for image and webview for external url's). This html is then thrown into a div with proper CSS to set every scene as fullscreen. Before replacing the html for the next scene in the playlist, I reset the "src" attribute to blank as mentioned in the following guide by google: https://docs.google.com/document/d/1T4YdSh9e1jOPt96DXRPy368RB8ewE4PkcHki2q1QnCc/edit#heading=h.m4o65g29lzb0 Everything happens inside one function, this function will call itself with a setTimeout set at the duration of that particular scene. Nowhere inside my code do I request the application to restart after any amount of time. In my background script I have called upon the API to keep the display and system awake (requestKeepAwake). Both devices are managed via the admin tool of google (admin.google.com) and are NOT set to restart. Why is my chromebox/chromebit restarting on it's own? Everything screams memory leak, but shouldn't a device as powerful as the Asus Chromebox be able to at least last a week or longer running video's/photo's and websites in a loop? I have attached the following files: 1 Image showing the boot up times of the Chromebit, and the other showing the boot up times of the Chromebox. The following dates are part of the test (which I ran multiple times): Chromebit: Start test on 04/14 at 10:05AM, restart happened at 04/16 at 10:45AM (lasted 48 hours) Chromebox: Start test on 04/14 at 10:04AM, restart happened at 04/16 at 5:42AM (lasted almost 44 hours) I also added the log files which I could get via the admin panel (these are both managed devices). Another strange thing to notice is that the Chromebit, which has a lot less CPU/GPU and memory than the Chromebox, lasted longer than the Chromebox! If anyone has any suggestions, what could I have missed? These devices should hold out longer than 44 hours non stop! Did this work before? No Chrome version: 56.0.2924.110 Channel: stable OS Version: 56.0.2924.110 Flash Version:
,
Apr 27 2017
Hi Bokan, Thanks for the reply! I forgot to mention the following: In my Proof of Concept described above I added a start button to start playing the videos/images and html. When I boot up the app and don't start the playing the content, the device doesn't reboot after any amount of time. I was able to keep it alive for more than a week. I have since then updated the code to include slide where 3 video's are playing a the same time. Ever since I added this slide, both devices run even less long. The chromebit reaches 26 hours or so and the Chromebox less than 48 hours. This again makes me assume a memory leak. No content ==> no reboot, more content (like 3 video's playing simultaneously) ==> faster reboot. What are your thoughts?
,
Apr 27 2017
+sque@ since you seem to have some bugs related to ChromeOS memory leaks. Any idea where to route this bug or how we might get some useful debug info?
,
Apr 27 2017
I'm not actively looking at memory leaks right now, but +bccheng might be. I'll stay in the loop to provide input as needed.
,
May 8 2017
I can give you the link to the Proof Of Concept app: https://chrome.google.com/webstore/detail/dgt-signage-poc/gekgpopkegkdpemgakhbleckcfiinlli Or do you have any suggestions on how I can get the debug data you need? I started another test on may 3rd, all 3 devices (2 chromeboxes and one chromebit) rebooted after 48.5 hours. I just collected the data via the admin console as a zip file just as I did before and attached both the data of one chromebox and one chromebit. Both devices rebooted after 48.5 hours of non stop playing on may 5th around 4:30AM. I hope you can find some more useful data in these logs. Kind
,
May 8 2018
Issue has not been modified or commented on in the last 365 days, please re-open or file a new bug if this is still an issue. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 9 2018
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by bokan@chromium.org
, Apr 19 2017Components: -Blink OS>Embedded OS>Kernel