New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 602111 link

Starred by 4 users

Issue metadata

Status: Archived
Owner: ----
Closed: Apr 2017
Cc:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: ----



Sign in to add a comment

Memory Usage Bug: Android KGSL Memory not released even after closing all tabs

Reported by sardas...@gmail.com, Apr 10 2016

Issue description

Chrome Version: 49.0.2623.105
OS: Android 6.0.0 
Total RAM : 2 GB
Stock Android : No Third Party UI skin bloats
 
Can you reproduce this memory bloat? Yes

What steps will reproduce this memory bloat?
(1) Freshly Reboot Android Device and wait for 5 mins for the system to get stable. 
(2) Keep tracking KGSL memory as well as Total memory via dumpsys in the background with adb shell during the whole experiment.  
(3) Default setting on chrome for tabs is "MERGE TAB AND APP --> OFF". Keep the same setting.
(4) Launch a TAB with a simple website (any simple website). The PSS memory usage as well as KGSL memory usage increases. Keep adding TABS one by one. Increase in memory observed (which is natural). 
(5) At some point the maximum number of tabs that are alive (not loading website again on going to that tab) are 7-8 Tabs. Press Home Button. Again launch chrome. The tabs are still alive on chrome.
(6) After reaching this concurrency, number of tabs start falling. /dev/kmsg observed for kill messages.
(7) Loop through the opened tabs one by one and launcher process (home button), the number of alive tabs fall further again. However, the KGSL memory consumption don't fall down. 
(8) Continue Looping with alive tabs (3-4 at some stage) and home button -> tab1, tab2, tab3, tab4, home. The KGSL memory didn't fall although only 4 tabs are alive. The number of tabs fall further to 2 tabs when looping. The KGSL memory by chrome is still equal to 8 tabs though only 2 tabs are alive. 
(9) At one point, the number of alive tabs fall to 0. Still the KGSL memory of chrome process (privileged process) is as high as 400-450 MB (which was equal to when 8 tabs were alive). 
(10) So even if there is no TAB alive currently, around 450 MB of memory is still held by chrome process. This kills other background process/services. Ideally chrome should have released this memory when tabs are closed/killed. 
(11) At this stage when chrome is pushed in background, the KGSL memory falls down, but when launched again, the KGSL memory shoots again to 450 MB, which is  very huge requirement at one shot. This causes other process/services getting killed unnecessarily. 
(12) THIS BEHAVIOR OF CHROME IS NOT OBSERVED WHEN THE SETTING IS CHANGED "MERGE TAB WITH APP --> ON". 
(13) My gut feeling is when tabs are not merged with apps, chrome is treated as single process within which tabs are sub process. When tabs increase, the whole chrome process KGSL memory usage increases by (number of tabs * ~KGSL memory for each tab). But when tabs are merged with apps, each tab is treated as individual process and KGSL memory of chrome:privileged process doesn't increases hugely. 
(14) This behavior is not observed with other browsers. 

Attaching logs with dumpsys and KGSL logs. Also attaching PID (ps) logs alongwith /sys/class/kgsl/kgsl/page_alloc logs. 


PID.txt corresponds to kgsl_live.txt(values in Bytes) at given time
PID_2.txt corresponds to kgsl_live_2.txt (values in Bytes)
PID_3.txt corresponds to kgsl_live_3.txt (values in Bytes)

I dug more into the details and hence spotted KGSL as issue. Attaching relevant logs. Couldn't follow JSON method of collecting logs for now to eliminate any disturbances due to other process (textpad, etc) getting launched on Android device.           

Please note that above experiment was done in one shot - dumpsys meminfo and kgsl_C.txt were collected continuously. Only PID* and kgsl_live* were collected at intervals. Clearly, it can be seen that at the end of experiment, there was no tab alive (no chrome:sandbox process), but still the KGSL memory occupied by chrome:provileged process was as high as 450 MB. See PID_3.txt and kgsl_live_3.txt file for this. 

Did someone just forgot to write a free() on closing tab? 
 
dumpsys_meminfo_bf9cd962_MLP.txt
404 KB View Download
dev-kmsg_bf9cd962_MLP.txt
4.7 MB View Download
kgsl_C_bf9cd962_MLP.txt
29.4 KB View Download
PID.txt
377 KB View Download
PID_2.txt
16.4 KB View Download
PID_3.txt
36.8 KB View Download
kgsl_live.txt
14.2 KB View Download
kgsl_live_2.txt
786 bytes View Download
kgsl_live_3.txt
3.6 KB View Download

Comment 1 Deleted

Labels: OS-Android
Cc: picksi@chromium.org
Project Member

Comment 4 by sheriffbot@chromium.org, Apr 24 2017

Status: Archived (was: Unconfirmed)
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

Comment 5 by sardas...@gmail.com, Apr 24 2017

Issue still exist

Sign in to add a comment