New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 53 users
Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug-Regression



Sign in to add a comment
Chrome eats all available memory, causing the system to swap and lose responsiveness
Reported by hufeng1...@gmail.com, Jul 12 2014 Back to list
UserAgent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36

Steps to reproduce the problem:
1. Your pc with linux x64 with 1GB or 2GB memory
2. Open chromium with about more than 10 tabs
3. chrome eat all memory, system slow and slow

What is the expected behavior?
control memory usage, or system slow down

What went wrong?

All my memory was eat by chrome, terrible

About memory Measuring memory usage in a multi-process browser
Summary 
Memory 
Browser	 Private	 Proportional
Chrome
1,158,644k	897,636k
Note: This page will show memory use for all running browsers, not just Chrome.

Processes 
Memory
PID	 Name	 Private	 Proportional
2546	
Browser
108,788k	106,508k
2566	
Sandbox helper
4,120k	12,924k
2596	
GPU

238,184k	107,924k
2576	
Zygote
5,204k	5,520k
2620	
Extension
Proxy SwitchySharp
18,160k	44,356k
2632	
Extension
AdBlock
122,932k	44,660k
2637	
Extension
LastPass: Free Password Manager
36,656k	46,356k
2642	
Extension
SpeakIt!
15,256k	44,064k
3034	
Tab
浏览协助:代理服务器和翻墙软件 - BBC中文网 - 服务专区
48,352k	59,084k
3321	
Tab
Google+
213,396k	60,200k
3447	
Tab
Pro Audio - ArchWiki
Ubuntu Studio - Wikipedia, the free encyclopedia
ubuntu realtime kernel - Google Search
Real Time [Linux-Sound]
low latency kernel cpu load high - Google Search
ecee.colorado.edu/~ecen5623/ecen/Overview_of_Real_Time_Linux.pdf
UbuntuStudio/RealTimeKernel - Community Help Wiki
125,548k	57,504k
3567	
Tab
http://www.google.de/search?hl=de&q=Real+Time+Linux+site%3Ahttp%3A%2F%2Fwww.linuxjournal.com%2F&btnG=Google-Suche&meta=] is not available
11,240k	44,052k
3578	
Tab
Intelligent Systems Division - Research Areas - Projects
20,940k	49,952k
4311	
Tab
Chrome is a memory hog.: chrome
How to tame Google Chrome's memory use - gHacks Tech News
4 ways to make Google Chrome use less memory
limit chrome memory usage - Google Search
88,644k	58,944k
6521	
Tab
chromium bug report - Google Search
Issues - chromium - An open-source project to help move the web forward. - Google Project Hosting
61,748k	56,136k
7331	
Tab
 Issue 389439  - chromium - Tripadvisor uses 100% CPU - An open-source project to help move the web forward. - Google Project Hosting
22,820k	52,012k
7606	
Tab (Chrome)
About Memory
16,656k	47,440k
Σ	1158644k	
(The memory usage of our renderer processes is slightly less accurate when they are sandboxed.)

Did this work before? N/A 

Chrome version: 35.0.1916.153  Channel: stable
OS Version: 
Flash Version: Shockwave Flash 14.0 r0
 
Here is screenshot, Chrome eat large amount of memory.
System page swaping, very slow down. Terrible experience
Screenshot from 2014-07-12 08:20:01.jpg
230 KB View Download
Comment 2 by a...@chromium.org, Jul 15 2014
Labels: Performance-Memory
Labels: nomedia
Labels: Needs-Feedback
No Luck, I am unable to reproduce the issue on Linux 12.04 and Chrome: 35.0.1916.153. Did this issue started recently ? 

Please let me know if you have added any extensions or apps in recent times which might have caused this hike in memory. If so, disable them and see how it goes, please update the bug with your findings.
My pc with OpenSUSE 13.1

Browser  Private	Proportional
Chrome  1,796,516k	1,109,260k

I am not sure it's a bug or not, but chrome eat most of my memory. can we prevent chrome use less memory? 

Firefox browser use less memory than chrome.

If memory all full used, the swap began, system load increase more high, low performance.

Comment 6 by fi...@mxd.cz, Jul 26 2014
my Ubuntu x64 with 4 GB RAM = same issue, swapping kills the OS = manual reboot
Good luck, man, i hope the developer will have the same low end dev box?

Or they all have high speicification laptop or PC , such as 512GB memory and 4 CPU with 16 core each? 
Comment 8 by fi...@mxd.cz, Jul 27 2014
in general, Chrome is not suitable as a browser for 1-2 GB machines as it uses more than a gig of RAM everytime
Comment 9 by rra...@gmail.com, Jul 27 2014
Have you tried disabling "Use hardware acceleration when available" under advanced settings? It has reduced memory usage for me.
Me too, using Mint 17 Cinnamon 64 bit.  I'd swear that Chrome never used this much memory in past editions. Many tabs consume 100+ megs.

I believe I've got 3 gigs of RAM - that should enough to run a browser!

(As an aside, I'd love to know how displaying a web page can use up 100 megs of memory...)
Comment 11 by zvasy...@gmail.com, Sep 16 2014
Have same bug here. Able to reproduce it with 99.9% probability.


Short description how this bug happens for me: I have a browser session with tons of tabs opened. And I keep browsing. At some moment after new tab started to open **everything** freezes. None of following does not respond: browser itself, other apps, de/wm, keyboard (even alt+ctrl+f* or alt+SysRq+[any of that letters]). Also its not possible to ssh from other box. You have two ways: reboot or wait. It may took from 1 min up yo 10. If you are lucky, and will close 1-2 tabs for somehow, everything will come back


Pretty sure that one of the parts of the problem is that you have memory leak(s) in code that is behind "gpu process". I may be reproduce this in next way. I start browser with one tab opened only. Remember amount of ram (as A) taken by gpu process. open chromium BTS. Open dozen bugs from list. Remember ram number again (as B). close them tabs with bugs. Remember again (as C).

for my case A < C < B, A * 2.5 ≈ B, B * 0.95 ≈ C


This started to happen after upgrade of Ubuntu from 12.04 to 14.04, (Chromium from 34 to 36). I am using Ubuntu 14.04 x86 with 8Gb of RAM and no swap
many chrome user has complain on the social network. did you really care about ?
http://weibo.com/1401880315/Bz1DNAp2t?type=comment#_rnd1417575249157
https://twitter.com/search?q=chrome%20memory&src=typd
http://s.weibo.com/weibo/chrome%2520%25E5%2586%2585%25E5%25AD%2598?topnav=1&wvr=6&b=1


User feel pain because chrome ate their memory
Browser	Private	Proportional
Chrome
2,219,816k	1,210,520k


Google Chrome	39.0.2171.71 (正式版本) 
修订版本	465742dffbc8f2edcb5dacd2afc8b095199172fc-refs/branch-heads/2171_62@{#12}
操作系统	Linux 
Blink	537.36 (@185310)
JavaScript	V8 3.29.88.17
Flash	15.0.0.239
用户代理	Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/39.0.2171.71 Safari/537.36
命令行	/usr/bin/google-chrome-stable --flag-switches-begin --enable-async-dns --enable-quic --use-simple-cache-backend=on --enable-spdy4 --flag-switches-end
可执行文件路径	/opt/google/chrome/google-chrome
个人资料路径	/home/netroby/.config/google-chrome/Default
其他变体	e9f4800b-39c30599
76b48ab8-c24eec89
c70841c8-4866ef6e
15e1b27b-3d47f4f4
1d3ad72e-1c1c261b
9e5c75f1-ad69ceb0
f79cb77b-3d47f4f4
24dca50e-837c4893
ca65a9fe-91ac3782
8d790604-9cb2a91c
4ea303a6-85fb2903
d8f57532-3f4a17df
61544484-ca7d8d80
9736de91-ca7d8d80
b2612322-f8cf70e2
5a3c10b5-e1cc0f14
244ca1ac-4ad60575
5e29d81-cf4f6ead
3ac60855-486e2a9c
246fb659-7158671e
f296190c-f5f3fe99
4442aae2-6e3b1976
ed1d377-e1cc0f14
75f0f0a0-a5822863
e2b18481-a90023b1
e7e71889-e1cc0f14
cbf0c14e-bf3e6cfd
Same in my case. I am using CentOS6.5 + Chrome Version 35
I am opening 6 windows in Vm having 8GB RAM and 4 cores - and within in 30 minutes entire memory get used up + 2G swap also occupied.
This resulting OOM-Killer to invoke and kill few of the highly scored Chrome process. 

How we can control the Chrome memory usage behavior . 
Shall we try from OS perspective by setting limits in limits.conf ?   

Me too,
I have linux ubuntu 14.04 x64 4gb and 4gb of swap

always happens the chrome spend 1.5 gb or more with 10+- tabs the problem is that i use eclipse and tomcat in the same time, so all my ram is eat, so my PC is too low,
swap stay in 500mb of usage with eclipse, tomcat and chrome opened.

chrome NEVER recycle the RAM, only if i close the tabs.
memory 2.png
161 KB View Download
memory 1.png
160 KB View Download
Comment 16 by muz...@gmail.com, Jan 4 2015
same issue since upgrading to linux kubuntu 14.04 x64 half a year ago. went back to firefox after 3 or 4 years using chromium - problem solved! seriously, while you wait for this issue getting solved: firefox has come a long way ;)
For those who try to reduce the memory usage, there is a command line argument you can add to the shortcut of Chrome:

--process-per-site

This causes Chrome to create less processes and that reduces the memory usage a bit.

Note that this also comes with its own weaknesses, which I assume the readers of this thread accept happily:
http://www.chromium.org/developers/design-documents/process-models#2_Process_per_Site

As a commentary, on that page is also described an option
http://www.chromium.org/developers/design-documents/process-models#TOC-Single-process
but at least in my computer it does not work or crashes, do not remember which way it went.
Comment 18 Deleted
I had the same problem.

Ubuntu 14.04 LTS x64, RAM: 4GB

Chrome ate up almost all the memory around 80%. I tried a few tips to avoid the
memory leaks and it helped me a lot. So thought its gonna help someone.

1. Disable the Hardware Acceleration
2. Disalble Running background apps when google chrome is closed
3. Delete Google Drive App if you installed from webstore (Which is running a seperate background process always and takes lots of memory)
4. Disable Unwanted Chrome Extensions
5. Monitor the extension time to time and disable if it behaves badly. Open chrome Task Manager (Shift + Esc) for Monitoring Chrome Process & extension

Thanks,
Comment 20 by djsty...@gmail.com, Mar 15 2015
Can confirm the problem (Debian Testing 64bit). Interesting fact I noticed: The memory usage is proportional to the available overall memory including swap. Just try activiating some swap space and monitor chrome's usage. It will terribly increase. One tab process showing a small picture can take over 600 MB (but only a fraction of it with fewer system memory). 

Also chrome keeps to hog RAM even after killing every tab and extension (via task manager). Also proportional to the overall memory. There are still several processes spawned and the core application seems to be the problem.
Comment 21 by fi...@mxd.cz, Mar 16 2015
I found out that the best thing is to kill the browser or exit.

killall works quite good ;-)

s pozdravem, Filip Oščádal
Ubuntu 14.10 x64

Same troubles here
gp3pgFz.png
90.2 KB View Download
Comment 23 by Deleted ...@, Apr 24 2015
Ubuntu 14.04 x64 same problem here, when the system gets out of RAM it almost freezes for a few seconds until you start killing things.
Same issue; but in my case the swap fills up while still having free memory, also I set vm.swappiness = 0 and no effect
Once I killed pretty much all of the processes on the system and the swap was still about 80% full (about 3 GB); while memory usage was reported less than 1GB. I suspect chromium causing something in the kernel or GPU driver to use the swap.
ubuntu 14.04 x86 (32bit).
# free
             total       used       free     shared    buffers     cached
Mem:       8285952    6381948    1904004    1000596       6344    1307060
-/+ buffers/cache:    5068544    3217408
Swap:      4194300    4171440      22860

# lspci -vvvv -s 01:00.0
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM] (prog-if 00 [VGA controller])
        Subsystem: ASUSTeK Computer Inc. Device 04a7
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 0, Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 45
        Region 0: Memory at d0000000 (64-bit, prefetchable) [size=256M]
        Region 2: Memory at fe9c0000 (64-bit, non-prefetchable) [size=128K]
        Region 4: I/O ports at d000 [size=256]
        [virtual] Expansion ROM at fe900000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Express (v2) Legacy Endpoint, MSI 00
                DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s <4us, L1 unlimited
                        ExtTag+ AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
                DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
                        RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
                        MaxPayload 128 bytes, MaxReadReq 512 bytes
                DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr- TransPend-
                LnkCap: Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Exit Latency L0s <64ns, L1 <1us
                        ClockPM- Surprise- LLActRep- BwNot-
                LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
                        ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
                LnkSta: Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
                DevCap2: Completion Timeout: Not Supported, TimeoutDis-, LTR-, OBFF Not Supported
                DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-, OBFF Disabled
                LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
                         Transmit Margin: Normal Operating Range, EnterModifiedCompliance- ComplianceSOS-
                         Compliance De-emphasis: -6dB
                LnkSta2: Current De-emphasis Level: -6dB, EqualizationComplete-, EqualizationPhase1-
                         EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
        Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit+
                Address: 00000000fee0300c  Data: 4142
        Capabilities: [100 v1] Vendor Specific Information: ID=0001 Rev=1 Len=010 <?>
        Capabilities: [150 v1] Advanced Error Reporting
                UESta:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UEMsk:  DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
                UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
                CESta:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
                CEMsk:  RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
                AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
        Kernel driver in use: radeon

# modinfo radeon | egrep "file|verma"
filename:       /lib/modules/3.13.0-51-generic/kernel/drivers/gpu/drm/radeon/radeon.ko
vermagic:       3.13.0-51-generic SMP mod_unload modversions 686 
# uname -a
Linux mormy 3.13.0-51-generic #84-Ubuntu SMP Wed Apr 15 12:11:46 UTC 2015 i686 i686 i686 GNU/Linux

xserver driver:
xserver-xorg-video-radeon                                   1:7.3.0-1ubuntu3.1



also, content of chrome://gpu

Graphics Feature Status
Canvas: Software only, hardware acceleration unavailable
Flash: Hardware accelerated
Flash Stage3D: Software only, hardware acceleration unavailable
Flash Stage3D Baseline profile: Software only, hardware acceleration unavailable
Compositing: Hardware accelerated
Multiple Raster Threads: Disabled
Rasterization: Software only, hardware acceleration unavailable
Threaded Rasterization: Enabled
Video Decode: Software only, hardware acceleration unavailable
Video Encode: Hardware accelerated
WebGL: Hardware accelerated
Driver Bug Workarounds
clear_uniforms_before_first_program_use
count_all_in_varyings_packing
disable_post_sub_buffers_for_onscreen_surfaces
init_texture_max_anisotropy
regenerate_struct_names
scalarize_vec_and_mat_constructor_args
Problems Detected
Accelerated 2d canvas is unstable in Linux at the moment
Disabled Features: accelerated_2d_canvas
Stage3D is not supported on Linux: 129848
Disabled Features: flash_stage3d
Accelerated video decode is unavailable on Mac and Linux: 137247, 133828
Disabled Features: accelerated_video_decode
GPU rasterization is blacklisted on non-Android: 362779
Disabled Features: gpu_rasterization
Clear uniforms before first program use on all platforms: 124764, 349137
Applied Workarounds: clear_uniforms_before_first_program_use
Mesa drivers in Linux handle varyings without static use incorrectly: 333885
Applied Workarounds: count_all_in_varyings_packing
Linux AMD drivers incorrectly return initial value of 1 for TEXTURE_MAX_ANISOTROPY: 348237
Applied Workarounds: init_texture_max_anisotropy
Disable partial swaps on linux drivers: 339493
Applied Workarounds: disable_post_sub_buffers_for_onscreen_surfaces
Always rewrite vec/mat constructors to be consistent: 398694
Applied Workarounds: scalarize_vec_and_mat_constructor_args
Linux AMD drivers handle struct scopes incorrectly: 403957
Applied Workarounds: regenerate_struct_names
Raster is using a single thread.
Disabled Features: multiple_raster_threads
Version Information
Data exported	5/6/2015, 12:29:31 AM
Chrome version	Chrome/41.0.2272.76
Operating system	Linux 3.13.0-51-generic
Software rendering list version	9.15
Driver bug list version	7.16
ANGLE commit id	unknown hash
2D graphics backend	Skia
Command Line Args	--ppapi-flash-path=/usr/lib/pepperflashplugin-nonfree/libpepflashplayer.so --ppapi-flash-version=13.0.0.182 --ppapi-flash-path=/usr/lib/adobe-flashplugin/libpepflashplayer.so --ppapi-flash-version --enable-pinch --flag-switches-begin --flag-switches-end
Driver Information
Initialization time	132
Sandboxed	false
GPU0	VENDOR = 0x1002, DEVICE= 0x6779
Optimus	false
AMD switchable	false
Driver vendor	Mesa
Driver version	10.1.3
Driver date	
Pixel shader version	1.30
Vertex shader version	1.30
Machine model name	
Machine model version	
GL_VENDOR	X.Org
GL_RENDERER	Gallium 0.4 on AMD CAICOS
GL_VERSION	3.0 Mesa 10.1.3
GL_EXTENSIONS	GL_ARB_multisample GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_copy_texture GL_EXT_polygon_offset GL_EXT_subtexture GL_EXT_texture_object GL_EXT_vertex_array GL_EXT_compiled_vertex_array GL_EXT_texture GL_EXT_texture3D GL_IBM_rasterpos_clip GL_ARB_point_parameters GL_EXT_draw_range_elements GL_EXT_packed_pixels GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_separate_specular_color GL_EXT_texture_edge_clamp GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_ARB_framebuffer_sRGB GL_ARB_multitexture GL_EXT_framebuffer_sRGB GL_IBM_multimode_draw_arrays GL_IBM_texture_mirrored_repeat GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_transpose_matrix GL_EXT_blend_func_separate GL_EXT_fog_coord GL_EXT_multi_draw_arrays GL_EXT_secondary_color GL_EXT_texture_env_add GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias GL_INGR_blend_func_separate GL_NV_blend_square GL_NV_light_max_exponent GL_NV_texgen_reflection GL_NV_texture_env_combine4 GL_S3_s3tc GL_SUN_multi_draw_arrays GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_EXT_framebuffer_object GL_EXT_texture_compression_s3tc GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_MESA_window_pos GL_NV_packed_depth_stencil GL_NV_texture_rectangle GL_ARB_depth_texture GL_ARB_occlusion_query GL_ARB_shadow GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat GL_ARB_window_pos GL_EXT_stencil_two_side GL_EXT_texture_cube_map GL_NV_depth_clamp GL_NV_fog_distance GL_APPLE_packed_pixels GL_APPLE_vertex_array_object GL_ARB_draw_buffers GL_ARB_fragment_program GL_ARB_fragment_shader GL_ARB_shader_objects GL_ARB_vertex_program GL_ARB_vertex_shader GL_ATI_draw_buffers GL_ATI_texture_env_combine3 GL_ATI_texture_float GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_MESA_pack_invert GL_NV_primitive_restart GL_ARB_depth_clamp GL_ARB_fragment_program_shadow GL_ARB_half_float_pixel GL_ARB_occlusion_query2 GL_ARB_point_sprite GL_ARB_shading_language_100 GL_ARB_sync GL_ARB_texture_non_power_of_two GL_ARB_vertex_buffer_object GL_ATI_blend_equation_separate GL_EXT_blend_equation_separate GL_OES_read_format GL_ARB_color_buffer_float GL_ARB_pixel_buffer_object GL_ARB_texture_compression_rgtc GL_ARB_texture_float GL_ARB_texture_rectangle GL_ATI_texture_compression_3dc GL_EXT_packed_float GL_EXT_pixel_buffer_object GL_EXT_texture_compression_dxt1 GL_EXT_texture_compression_rgtc GL_EXT_texture_mirror_clamp GL_EXT_texture_rectangle GL_EXT_texture_sRGB GL_EXT_texture_shared_exponent GL_ARB_framebuffer_object GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_packed_depth_stencil GL_ARB_vertex_array_object GL_ATI_separate_stencil GL_ATI_texture_mirror_once GL_EXT_draw_buffers2 GL_EXT_draw_instanced GL_EXT_gpu_program_parameters GL_EXT_texture_array GL_EXT_texture_compression_latc GL_EXT_texture_integer GL_EXT_texture_sRGB_decode GL_EXT_timer_query GL_OES_EGL_image GL_ARB_copy_buffer GL_ARB_depth_buffer_float GL_ARB_draw_instanced GL_ARB_half_float_vertex GL_ARB_instanced_arrays GL_ARB_map_buffer_range GL_ARB_texture_rg GL_ARB_texture_swizzle GL_ARB_vertex_array_bgra GL_EXT_texture_swizzle GL_EXT_vertex_array_bgra GL_NV_conditional_render GL_AMD_conservative_depth GL_AMD_draw_buffers_blend GL_AMD_seamless_cubemap_per_texture GL_AMD_shader_stencil_export GL_ARB_ES2_compatibility GL_ARB_blend_func_extended GL_ARB_debug_output GL_ARB_draw_buffers_blend GL_ARB_draw_elements_base_vertex GL_ARB_explicit_attrib_location GL_ARB_fragment_coord_conventions GL_ARB_provoking_vertex GL_ARB_sampler_objects GL_ARB_seamless_cube_map GL_ARB_shader_stencil_export GL_ARB_shader_texture_lod GL_ARB_texture_cube_map_array GL_ARB_texture_multisample GL_ARB_texture_rgb10_a2ui GL_ARB_uniform_buffer_object GL_ARB_vertex_type_2_10_10_10_rev GL_EXT_provoking_vertex GL_EXT_texture_snorm GL_MESA_texture_signed_rgba GL_NV_texture_barrier GL_ARB_get_program_binary GL_ARB_robustness GL_ARB_shader_bit_encoding GL_ARB_timer_query GL_ARB_transform_feedback2 GL_ARB_transform_feedback3 GL_NV_vdpau_interop GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 GL_ARB_base_instance GL_ARB_conservative_depth GL_ARB_internalformat_query GL_ARB_map_buffer_alignment GL_ARB_shading_language_420pack GL_ARB_shading_language_packing GL_ARB_texture_storage GL_ARB_transform_feedback_instanced GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_transform_feedback GL_AMD_shader_trinary_minmax GL_ARB_clear_buffer_object GL_ARB_invalidate_subdata GL_ARB_texture_storage_multisample GL_ARB_vertex_attrib_binding GL_KHR_debug GL_ARB_texture_mirror_clamp_to_edge GL_ARB_vertex_type_10f_11f_11f_rev
Window system binding vendor	SGI
Window system binding version	1.4
Window system binding extensions	GLX_ARB_create_context GLX_ARB_create_context_profile GLX_ARB_fbconfig_float GLX_ARB_framebuffer_sRGB GLX_ARB_multisample GLX_EXT_create_context_es2_profile GLX_EXT_framebuffer_sRGB GLX_EXT_import_context GLX_EXT_texture_from_pixmap GLX_EXT_visual_info GLX_EXT_visual_rating GLX_MESA_copy_sub_buffer GLX_OML_swap_method GLX_SGI_swap_control GLX_SGIS_multisample GLX_SGIX_fbconfig GLX_SGIX_pbuffer GLX_SGIX_visual_select_group GLX_INTEL_swap_event
Window manager	Compiz
XDG_CURRENT_DESKTOP	Unity
GDMSESSION	ubuntu
Compositing manager	Yes
Direct rendering	Yes
Reset notification strategy	0x8261
GPU process crash count	2
Log Messages
[14060:14060:0501/214351:ERROR:sandbox_linux.cc(325)] : InitializeSandbox() called with multiple threads in process gpu-process
GpuProcessHostUIShim: The GPU process crashed!
[23884:23884:0503/233607:ERROR:sandbox_linux.cc(325)] : InitializeSandbox() called with multiple threads in process gpu-process
[23884:23884:0505/075615:WARNING:file_descriptor_set_posix.cc(30)] : FileDescriptorSet destroyed with unconsumed descriptors: 0/1
[23884:23884:0506/001944:ERROR:gles2_cmd_decoder.cc(1926)] : [GroupMarkerNotSet( crbug.com/242999 )!:38DB78A0]GL ERROR :GL_OUT_OF_MEMORY : GLES2DecoderImpl::DoReleaseTexImage2DCHROMIUM: <- error from previous GL command
[23884:23884:0506/001944:ERROR:gles2_cmd_decoder.cc(4028)] : Error: 5 for Command kReleaseTexImage2DCHROMIUM
[23884:23884:0506/001944:ERROR:gles2_cmd_decoder.cc(10809)] : [GroupMarkerNotSet( crbug.com/242999 )!:98FA32BE]GL ERROR :GL_OUT_OF_MEMORY : glTexStorage2DEXT: <- error from previous GL command
[23884:23884:0506/001944:ERROR:gles2_cmd_decoder.cc(10811)] : [GroupMarkerNotSet( crbug.com/242999 )!:98FA32BE]GL ERROR :GL_OUT_OF_MEMORY : glTexStorage2DEXT:
[23884:23884:0506/001944:ERROR:gles2_cmd_decoder.cc(4028)] : Error: 5 for Command kTexStorage2DEXT
[23884:23884:0506/001944:ERROR:gles2_cmd_decoder.cc(3200)] : GLES2DecoderImpl: Context lost during MakeCurrent.
[23884:23884:0506/001944:ERROR:gles2_cmd_decoder.cc(3200)] : GLES2DecoderImpl: Context lost during MakeCurrent.
[23884:23884:0506/001944:ERROR:gles2_cmd_decoder.cc(3200)] : GLES2DecoderImpl: Context lost during MakeCurrent.
[23884:23884:0506/001944:ERROR:gles2_cmd_decoder.cc(3200)] : GLES2DecoderImpl: Context lost during MakeCurrent.
[23884:23884:0506/001944:ERROR:gles2_cmd_decoder.cc(3200)] : GLES2DecoderImpl: Context lost during MakeCurrent.
[23884:23884:0506/001944:ERROR:gles2_cmd_decoder.cc(3200)] : GLES2DecoderImpl: Context lost during MakeCurrent.
[23884:23884:0506/001944:ERROR:gles2_cmd_decoder.cc(3200)] : GLES2DecoderImpl: Context lost during MakeCurrent.
GpuProcessHostUIShim: The GPU process crashed!
[22633:22633:0506/001945:ERROR:sandbox_linux.cc(325)] : InitializeSandbox() called with multiple threads in process gpu-process
[22633:22633:0506/002745:WARNING:file_descriptor_set_posix.cc(30)] : FileDescriptorSet destroyed with unconsumed descriptors: 0/1
[22633:22633:0506/002804:WARNING:file_descriptor_set_posix.cc(30)] : FileDescriptorSet destroyed with unconsumed descriptors: 0/1
At least under Windows, when killing tab processes via Chrome Task Manager, the Chrome main process memory commit may increase drastically afterwards. Seems like some additional leak related to killing tab processes. It also appears to me that this does not happen always.
Same issue here on Kubuntu 14.04
Linux IMS-ADAM 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Chrome: Version 43.0.2357.81 (64-bit) (And many earlier versions)
Chrome reports the following memory amounts:
5,461,084k Private and 596,796k proportional overall
3,585,240k private and 92,748k proportional being the root browser process. 

Linux tells me chrome's root process has 12.1G Virtual, 3.8G RES, and only 99M shared. 
I have 8GB of RAM along with 10GB of swap, both fill completely.
Running `pkill -9 chrome` usually drops total used RAM to 1-3GB. 


I have 16GB memory now, And Chrome still eat all of my memory ,then cause system hangs up.
Good job, chrome, you shoot me on my feets
Years goes, You won't fixes this bugs for us. 
Hate you, Google.
My solution was, put 8GB RAM in my laptop, now google chrome uses 1~2gb with 10 or more tabs 
Upgraded to Ubuntu 15.04 last week, haven't had any issues with chrome so far. May be a weird bug only on 14.04. 
Status: Untriaged
Summary: Chrome eats all available memory, causing the system to swap and lose responsiveness (was: Chrome eat all the memory, then system slow like shit)
Comment 33 by Deleted ...@, Aug 15 2015
Same issue here. Using 4GB RAM. Chromium eventually freezes the whole system. Am using Arch. These guys need to do something about it. Never had such a terrible experience before with any other system app. I have to restart the window manager/system at least 5 times a day.
Comment 34 by Deleted ...@, Nov 16 2015
It basically gets my desktop stuck. Ok its an "old" PC but with 8GB of ram.
Comment 35 by pur3m...@gmail.com, Nov 16 2015
Just hit this. Upgraded from Ubuntu 12 to 14.04. It was perfect on 12, but now while it can view some simple sites, some can totally kill it (Gmail, youtube) - it just munches through all memory and then right into swap.

It's so fast and vicious I have to switch to text-mode console, and even then it takes maybe a minute to log in and `killall chrome`. Sadly I'm writing this on a second computer, and the original will now be forced to use Firefox.

If I can run anything that will help debug please let me know. I tried disabling GPU just in case, but no luck,
The one way that I have found to fix it, was put more 4gb on my Ubuntu 14.02 X64, now I have  8gb. lamentably
I think that the problem it is on Ubuntu 14.x because on Ubuntu 12.x I have not this problem
Comment 38 by pur3m...@gmail.com, Nov 17 2015
Just a bit more info: It happened for me on Chromium too - after looking around there were some suggestions it might be related to the video card driver (despite my trying to turn off acceleration).

And going to a WebGL site instantly killed it.

I can't be sure exactly which driver I was using but I think Ubuntu could have reverted to nouveau after the update, and that was causing issues. After switching to the NVIDIA binary (346.96) via the 'Additional Drivers' menu the problem *appears* to be fixed (it hasn't crashed in a few hours at least), so it might be my previous post was a bit of a red herring. 

Sorry about that.
Comment 39 by djsty...@gmail.com, Nov 17 2015
Hello,

I don't think it's a video driver problem. Although such exist too. I'm using AMD(ATI) and chrome is using all my memory no matter which driver I use. 

Since the latest updates I noticed some changes: Chrome seems to use even more memory but there's something interesting new. The task manager only shows the active tabs (of course) but the memory consumption increases without being recorded. If you close the task manager and open it again there suddenly are lots of new processes, mostly already killed ones that seem to respawn in the background consming lots of memory. The corresponding tabs are still dead but the processes exist. Then you can kill them again which frees a lot of memory (the task manager doesn't remove them - only shows "N/A" until you restart the manager). So there seems to be some bug with the process handling and monitoring. Some processes seem to go rogue without chrome even noticing. 
One side effect: CPU consumption now increases up to 50% although chrome is idle and browser starts to become slow. I guess it's connected to killing those rogue processes. 
The only real solution still is to kill and restart the browser. 

Also the memory consumption is still not connected to the actual memory requirements. Updating my memory to 6 GB increased the consumption by the same factor. It's still like some internal function was like "always block 80% of available memory". So even if you have 100 GB it would use almost all of it. You can test it by faking more memory with swap space. 
Comment 40 by pur3m...@gmail.com, Nov 17 2015
Hmm, it just happened again. So no, not video drivers.

Anyone at Google: is there something I can run or some log I can look at to see what exactly was using all the memory after the crash? I've had issues with Chrome and the Gnome keychain before, but this is so bad I can't even start `top` to see what's wrong.
Comment 41 by Deleted ...@, Nov 23 2015
    Google Chrome has been freezing my system. Linux Mint 17.1 with regular updates. At first I had to just reboot the machine, not knowing what froze the system. As I dug into it I found Google Chrome was freezing the system. This is how I found that and now saved my system from reboot. 
    On a second system, I ssh into the first system and run htop. This has a nice color bar for the swap space. The memory is still available, cpu is still available, but swap space starts to nibble away across the screen. I watched this several times go to max and freeze the system. chrome was running. So I started to kill the highest listed chrome processes. When I hit the right chrome proccess (way to many), poof, swap space would drop back to what it was. My system was saved from reboot. 
    So for now, I keep an extra SSH window open on a second system. When the system stops responding to clicks. I quickly check the second machine for swap space increase. If it is happening, I start killing Google Chrome processes.
    Now your mileage may vary. I am sticking to this until Google Chrome (or a 3rd party sub library) is fixed.

After one year and several months. You improve nothing. My Win PC get stuck by chrome, My Linux get stuck by chrome, My Mac get stuck by chrome.

Good job, google chrome. you win.
Comment 43 by brane...@gmail.com, Dec 17 2015
Same here. At firtst I thought that this was something with my partcular Chrome version or perhaps some malitious webpage starting some especially heinous javascript, then that it might be some driver or library issue, but after a while it became obvous that this is probably something within the Chrome.

If I catch it early enough, I can save the system by killing all Chrome instances. Closing individual tabs has marginal effect.

My system:

Machine: Phenom 955BE stock with 8GiB DDR3 RAM and RAdeon HD-6850 GFX : 3 monitor setup ( 3 x 1600 x1200)

OS: Gentoo 64-bit mostly stable with some bits unstable, CHrome among them.

compiler: gcc-5.3.0 
glibc: 2.21
kernel: gentoo-sources-4.14
video driver: open-source radeon within kernel
chromium: 47.0.2526.80
mesa:  11.1.0 

















Cc: rnimmagadda@chromium.org
Labels: -nomedia Nomedia
Unable to repro this issue on Ubuntu Trusty (14.04) for Google Chrome Stable Version - 49.0.2623.87

@hufeng1987: Could you please perform the steps mentioned beneath and let us know your observations.

1. Update your Google Chrome to Latest Stable Version - 49.0.2623.87
2. Re-test the same on a clean profile [chrome://settings -> Add Person]

Thank you.
I've just tried updating to the latest beta, 50.0.2661.26, and still have problems (albeit using my original profile).

While Chrome doesn't seem to use loads of memory, I just caught gnome-keyring-daemon's memory usage rising by a few megabytes every second(!) and this appears to be what causes it for me.

While it's not Chrome (in my case), it *is* caused by Chrome somehow. Everything is fine until Chrome starts, then gnome-keyring-daemon goes insane and uses up all my RAM.


Labels: Te-NeedsFurtherTriage
Chrome 50.0 with Ubuntu 16.04 x64 is ridiculously bad on my PC, lots of memory per tab and after a while machine freezes (going nuts attempting to swap memory) until OOM kills whatever in Chrome is causing the problem.
Chrome 50.0.2661.94 (64-bit), ubuntu 16 x64,  still  eating the memory.

15 tabs = 1.6GB

The unique solution is really buy more memory because unfortunately chrome is the best browser, lol

my linux

$ lsb_release -a && cat /proc/version
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04 LTS
Release:	16.04
Codename:	xenial
Linux version 4.4.0-21-generic (buildd@lgw01-21) (gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2) ) #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016
Selection_011.jpg
63.9 KB View Download
Comment 49 by a...@chromium.org, Jul 15 2016
Cc: tkonch...@chromium.org
 Issue 588707  has been merged into this issue.
Components: Internals
Labels: -Needs-Feedback -Te-NeedsFurtherTriage TE-NeedsTriageHelp
Ubuntu GNOME 16.04.1 LTS 64 bit, 3 Gb RAM, same problem.
+1

Chromium is almost unusable on not hi-end computers with many extensions.

Also after start I need to wait ~one hour for gnome-keyring-daemon to make something.
Comment 53 Deleted
Ubuntu Gnome, 16.10 64 bit, I have 8GB Ram available, Chromium will use all of it over time.
Chromium 53.0.2785.143 Built on Ubuntu
Ubuntu, 16.04.1 64 bit, Also have 8GB Ram available, Chromium will use all RAM over time.
xubuntu 16.04 64bit, chromium55.0.2883.87, same problem
Comment 57 by dandv@google.com, Jan 10 2017
32GB RAM desktop, Chrome uses 20GB+ of it, with ~140 tabs.
Comment 58 Deleted
Linux Mint 17.3
Linux 3.19.0-32-generic #37~14.04.1-Ubuntu SMP Thu Oct 22 09:41:40 UTC 2015 x86_64 GNU/Linux

I tried with 4,8 and 16Gb RAM and 8, 16, 32 GB swap.

Every time the same scenario: I am reading articles, opening them one by one. At the moment when I navigate to the page with extensive usage of graphics or a lot of JS the system goes out of memory, and ENTIRE PC become unresponsive.

Sometimes I can kill several chromium threads with highest memory consumption (I am keeping console with HTOP for this purposes). Do you think this is a good solution? I don't think so.

I am trying to find a solution, but I still didn't got any..
List is growing in size. lots of people facing the issue yet no solution has been provided. what a shame!. At least a fix!.
Same on Ubuntu Gnome 16.04 and previous versions for ages.
Tabs on Chromium and Chrome usually eat more than 150mb RAM each. Under Windows 10 on the same machine the memory usage is surprisingly lower, averaging 30mb for each tab. Chrome/Chromium still needs a crazy amount of work to run properly on linux :(
Cc: danakj@chromium.org thomasanderson@chromium.org
Labels: -Nomedia Needs-Feedback
It's not clear to me what this bug is really, there's a wide range of comments here from what I think is reports of memory leaks to general too much memory.

If someone has a specific case of using too much memory that you'd like us to look at we will need either:

1. Steps to reproduce it so we can do something
2. A trace showing the memory and where it is going https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/README.md

If you have chrome growing to use more and more memory may I suggest that you
a) Grab a trace when chrome is using less memory
b) Wait and grab another trace when chrome is using more memory

Then we have something to compare.
I've got a trace from no tabs open, with the browser process using 800+ mb. Most of it is in the malloc category.


I'd rather not post the trace publicly, in case it contains sensitive data.

Screenshot from 2017-02-01 21-27-45.png
63.8 KB View Download
Can you expand the Native heap bullets? You could email it directly if you're comfortable with that, if not then expanding everything fully would be helpful.
Ok, I'll send you an email since these screenshots don't seem very helpful.
Screenshot from 2017-02-01 22-05-59.png
56.0 KB View Download
Screenshot from 2017-02-01 22-06-20.png
140 KB View Download
Thank you for the trace.

I guess for this leak we'll need to dig deeper. There is a command line flag you can use to get more detailed tracing of native memory like this. But you'd have to run chrome with --enable-heap-profiling.

These are instructions on how to run chrome with a flag: https://www.chromium.org/for-testers/command-line-flags

If you did it right you'll see the flag in chrome://version

It is unfortunate they're not traced better here, but if you don't mind running chrome with that flag and getting a trace when it happens again, that would be really helpful. Let me know if you have any questions, and thank you very much for helping.

One other question: Is this on Windows 10?
> One other question: Is this on Windows 10?

Nevermind, I see it's linux in the metadata.
Oh, and I see this is Chrome 55, if you can get 56 the current stable that'd be good. I'm not sure the flag is there in 55.
I'll try that flag.

It's Ubuntu 16.04. I haven't noticed a leak this severe on Windows 10.
It looks like the biggest leak is in gdbus:
Screenshot from 2017-02-02 10-04-42.png
151 KB View Download
Thanks, in the traces I see

malloc size goes from 96.2MB to 117.5MB = 81.3MB rise

Within that:

gdbus goes from 12.6MB to 25.4MB = 12.8MB rise, with avg of 0.1KB/alloc

CrBrowserMain from 13.5MB to 17.6MB = 4.1MB rise

Chrome_FileThread from 7MB to 12.6MB = 5.6MB rise


It would be interesting to see a comparison from after chrome reaches a steady state as allocations around startup may be introducing a bunch of noise. Lots of WorkerPool threads are a bit larger contributing to the overall increase as well.
Also when I double click the "Thread: gdbus" entry it says "Cannot break down by stack frame any further".
I've got another trace for a longer lived browser. In this case the browser process is up to 311MB with 186MB dirty, with no tabs (but a fair number of extensions).

The tracer pointed out that https://www.reddit.com/r/GameDeals/ seems to be triggering a leak of 3-4MB in the browser on each load, other sites also add memory but perhaps less.

In this trace, of the total 162MB taken by malloc, the largest memory consumer in the browser process is again the gdbus thread with 63MB. The next closest thread is the Chrome_DBThred with 13MB.

Of course, we don't have tracing on gdbus so it's not attributed further.
I also see my browser memory increase with each reload of https://www.reddit.com/r/GameDeals/ and not go down after closing the window.
When I do the same on TOTish with only 1 extension (uBlock) I don't see the memory change occur. I might see a smaller increase but its harder to say. After refreshing a lot I do see a larger CrBrowserMain thread with the majority difference I think being under RunTask->PostTask-><other>. The gdbus thread stays small so that seems unrelated to the page somehow. I wonder if there are 2 leaks going on for this user. I need to try with more extensions installed.
I tried installing a lot of extensions but reloading the reddit site is not growing my browser process in my TOT build.
I think I know what causes the gdbus leak.
I ran dbus-monitor, and noticed that each time I open https://www.reddit.com/r/GameDeals/, Chrome asks for and receives all my saved passwords from /org/freedesktop/secrets.
I created a clean chrome profile with google-chrome-unstable, and there didn't seem to be a leak there (it stabilized at about 138 MB for the Browser process, with gdbus taking just 32k). Then I saved a single password in that profile, and now gdbus is at 900 kB already.
The gdbus thread might leak some minimal amount of memory even when there are no passwords, because I did see a constant increase even then, but the end result was just 32k.
I've exported all my passwords using this hidden feature: https://www.ghacks.net/2017/01/05/chrome-import-export-passwords/
Then I deleted them all from my three profiles (the browser process ended up at 1.5gb after this, so the same leak probably happens when deleting passwords too), then I went into seahorse (gnome's password manager) and deleted a couple more that were not showing up in chrome, but were being sent to chrome via dbus. Then I verified via dbus-monitor that no passwords are being returned.

I've been using the browser like this for a few hours, and it's much, much better. There still seems to be a small leak, as I'm up to 257m from 248m yesterday. It sometimes goes down, but overall it's rising.
@Comment 78 by nx.devn...@gmail.com

Hey, I think you are right!!!, I ve tested it and makes sense, my chrome profile has passwords of more than 3 years of registrations in all internet, then my chrome instances eats 3GB of memory, creating a clean profile it takes something around 500MB~ with the same number of tabs(7)
Cc: cfroussios@chromium.org
Labels: -Type-Bug Type-Bug-Regression
Owner: thomasanderson@chromium.org
Status: Started
thanks #77/78 for the instructions, I'll see if I can reproduce

+cfroussios@ who's done a lot of work recently in oscrypt/libsecret land
Labels: -Needs-Feedback -TE-NeedsTriageHelp
Labels: -Pri-2 Pri-1
Owner: cfroussios@chromium.org
Status: Assigned
I ran an lsan build (output attached) and indeed there are leaks related to libsecret.  I thought we had lsan bots which would have caught this??

I didn't take a look at every detection, but one of them is due to:
https://cs.chromium.org/chromium/src/components/os_crypt/key_storage_libsecret.cc?rcl=21b6f3db42a1ff35b33993812b2fd851922c4770&l=79
which is missing a g_list_free[_full]

Over to cfroussios@ for the fix.  We'll also want a merge to M56 and M57.
leaks.txt
77.7 KB View Download
> I thought we had lsan bots which would have caught this??
by design LSan does not catch anything which has a pointer (owning or just naked) to the heap objects. It can detect only orphaned heap areas.
So if you: for(i=0; i < 10000000; i++) vector.push_back(new WhateverLargeThing()) LSan will never complain about that.

Glad to see that the culprit was found here. 
If that turns out to not be the case and you have a repro, next time you can just:
1. start chrome with --enable-heap-profiling
2. use chrome://tracing + memory-infra to narrow down to the code that allocated stuff.

See https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/heap_profiler.md for more
g_list_free is not missing in KeyStorageLibsecret
https://cs.chromium.org/chromium/src/components/os_crypt/key_storage_libsecret.cc?rcl=21b6f3db42a1ff35b33993812b2fd851922c4770&l=48

I haven't found what is being leaked yet, but in any case, oscrypt can't be responsible for leaks of this size, since the methods in question are called only once per run. It sounds like Password Manager is the real problem. Adding vabr@ as an FYI.

There is unfortunately also the possibility that the bug is in libsecret itself. One of the many calls that leak is https://cs.chromium.org/chromium/src/components/os_crypt/libsecret_util_linux.cc?rcl=418400229957dc4f45021047cd1fcdb751ed9590&l=143, where it is easier to see that we don't leak something ourselves. The only libsecret cleanup function I see is https://people.gnome.org/~stefw/libsecret-docs/SecretService.html#secret-service-disconnect and it doesn't appear to fix it.
This could perhaps be used to help find the leaks more precisely, but requires a custom build of chrome so not something for users really. But since we have a repro: https://chromium.googlesource.com/chromium/src/+/master/docs/memory-infra/heap_profiler.md#Native-stack-traces
Cc: vabr@chromium.org
I've opened https://bugzilla.gnome.org/show_bug.cgi?id=778350 for libsecret.

Are you sure you're looking at the right code?
From what I can understand, this looks like the code that gets all the passwords from libsecret: https://cs.chromium.org/chromium/src/chrome/browser/password_manager/native_backend_libsecret.cc?q=secret_password_store_sync&dr=C&l=418

and the leak happens when I have a lot of passwords in the keyring, so the leak should be there somewhere.
I think the problem is that you have to call g_list_free_full(found, g_object_unref), otherwise the SecretItems in the list are not freed.
Could you please try g_list_free_full instead of g_list_free to see if that fixes the bug? I wrote a simple test program for https://bugzilla.gnome.org/show_bug.cgi?id=778350 that leaks even with g_list_free_full, but maybe it'll fix the leak in Chrome.
Project Member Comment 91 by bugdroid1@chromium.org, Nov 10
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/a63b2ddd636c62a3fe3f5e46c6c951e9fce23993

commit a63b2ddd636c62a3fe3f5e46c6c951e9fce23993
Author: Christos Froussios <cfroussios@chromium.org>
Date: Fri Nov 10 10:22:24 2017

🔐 Call g_object_unref on lists returned by secret_service_search

We currently do not seem to be properly deleting SecretItems.

The destruction of SecretItems is undocumented, but g_object_unref
appears to have been used in other codebases for this purpose.

Bug: 393395
Change-Id: I046911136bac266c0e1a42b09a8a0cb79b678f4a
Reviewed-on: https://chromium-review.googlesource.com/758851
Reviewed-by: Vaclav Brozek <vabr@chromium.org>
Commit-Queue: Christos Froussios <cfroussios@chromium.org>
Cr-Commit-Position: refs/heads/master@{#515522}
[modify] https://crrev.com/a63b2ddd636c62a3fe3f5e46c6c951e9fce23993/chrome/browser/password_manager/native_backend_libsecret.cc

I've tried this fix myself, unfortunately it does not fix the memory leak.
Also, there are other g_list_free's that need to be fixed in other files.
In src/components/os_crypt/key_storage_libsecret.cc, ToSingleSecret doesn't always free the list (it returns early without freeing the list if first == nullptr), and it also uses g_list_free instead of g_list_free_full.
And in src/components/os_crypt/libsecret_util_linux.cc there's a g_list_free that should also be a g_list_free_full.

There are other g_list_free's in Chromium's source, but those do not have to free their elements.

Project Member Comment 94 by bugdroid1@chromium.org, Nov 10
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/707f4c1edd205d63db1c981891fe85feadfdab6d

commit 707f4c1edd205d63db1c981891fe85feadfdab6d
Author: Colin Blundell <blundell@chromium.org>
Date: Fri Nov 10 13:04:51 2017

Revert "🔐 Call g_object_unref on lists returned by secret_service_search"

This reverts commit a63b2ddd636c62a3fe3f5e46c6c951e9fce23993.

Reason for revert: Seems to cause a unittest failure on Linux MSAN:

https://logs.chromium.org/v/?s=chromium%2Fbb%2Fchromium.memory%2FLinux_MSan_Tests%2F5764%2F%2B%2Frecipes%2Fsteps%2Funit_tests%2F0%2Flogs%2FNativeBackendLibsecretTest.PSLMatchingDisabledForNonHTMLForms%2F0

Original change's description:
> 🔐 Call g_object_unref on lists returned by secret_service_search
> 
> We currently do not seem to be properly deleting SecretItems.
> 
> The destruction of SecretItems is undocumented, but g_object_unref
> appears to have been used in other codebases for this purpose.
> 
> Bug: 393395
> Change-Id: I046911136bac266c0e1a42b09a8a0cb79b678f4a
> Reviewed-on: https://chromium-review.googlesource.com/758851
> Reviewed-by: Vaclav Brozek <vabr@chromium.org>
> Commit-Queue: Christos Froussios <cfroussios@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#515522}

TBR=vabr@chromium.org,cfroussios@chromium.org

Change-Id: I99edccd11818f72168d1bd2d7de43ccd182e83e6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 393395
Reviewed-on: https://chromium-review.googlesource.com/763311
Reviewed-by: Colin Blundell <blundell@chromium.org>
Commit-Queue: Colin Blundell <blundell@chromium.org>
Cr-Commit-Position: refs/heads/master@{#515537}
[modify] https://crrev.com/707f4c1edd205d63db1c981891fe85feadfdab6d/chrome/browser/password_manager/native_backend_libsecret.cc

Sign in to add a comment