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 59 users

Issue metadata

Status: Fixed
Closed: Feb 2018
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 1
Type: Bug-Regression

Sign in to add a comment

Issue 393395: Chrome eats all available memory, causing the system to swap and lose responsiveness

Reported by, Jul 12 2014

Issue description

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
Browser	 Private	 Proportional
1,158,644k	897,636k
Note: This page will show memory use for all running browsers, not just Chrome.

PID	 Name	 Private	 Proportional
108,788k	106,508k
Sandbox helper
4,120k	12,924k

238,184k	107,924k
5,204k	5,520k
Proxy SwitchySharp
18,160k	44,356k
122,932k	44,660k
LastPass: Free Password Manager
36,656k	46,356k
15,256k	44,064k
浏览协助:代理服务器和翻墙软件 - BBC中文网 - 服务专区
48,352k	59,084k
213,396k	60,200k
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
UbuntuStudio/RealTimeKernel - Community Help Wiki
125,548k	57,504k
Tab] is not available
11,240k	44,052k
Intelligent Systems Division - Research Areas - Projects
20,940k	49,952k
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
chromium bug report - Google Search
Issues - chromium - An open-source project to help move the web forward. - Google Project Hosting
61,748k	56,136k
 Issue 389439  - chromium - Tripadvisor uses 100% CPU - An open-source project to help move the web forward. - Google Project Hosting
22,820k	52,012k
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
Showing comments 7 - 106 of 106 Older

Comment 7 by, Jul 26 2014

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, 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, Jul 27 2014

Have you tried disabling "Use hardware acceleration when available" under advanced settings? It has reduced memory usage for me.

Comment 10 by, Aug 30 2014

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, 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

Comment 12 by, Dec 3 2014

Comment 13 by, Dec 3 2014

Browser	Private	Proportional
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
用户代理	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

Comment 14 by, Jan 2 2015

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 ?

Comment 15 by, Jan 4 2015

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, 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 ;)

Comment 17 by, Jan 7 2015

For those who try to reduce the memory usage, there is a command line argument you can add to the shortcut of Chrome:


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:

As a commentary, on that page is also described an option
but at least in my computer it does not work or crashes, do not remember which way it went.

Comment 18 Deleted

Comment 19 by, Mar 11 2015

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


Comment 20 by, 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, 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

Comment 22 by, Apr 3 2015

Ubuntu 14.10 x64

Same troubles here
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.

Comment 24 by, May 5 2015

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

Comment 25 by, May 5 2015

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
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/ --ppapi-flash-version= --ppapi-flash-path=/usr/lib/adobe-flashplugin/ --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_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
Compositing manager	Yes
Direct rendering	Yes
Reset notification strategy	0x8261
GPU process crash count	2
Log Messages
[14060:14060:0501/] : InitializeSandbox() called with multiple threads in process gpu-process
GpuProcessHostUIShim: The GPU process crashed!
[23884:23884:0503/] : InitializeSandbox() called with multiple threads in process gpu-process
[23884:23884:0505/] : FileDescriptorSet destroyed with unconsumed descriptors: 0/1
[23884:23884:0506/] : [GroupMarkerNotSet( )!:38DB78A0]GL ERROR :GL_OUT_OF_MEMORY : GLES2DecoderImpl::DoReleaseTexImage2DCHROMIUM: <- error from previous GL command
[23884:23884:0506/] : Error: 5 for Command kReleaseTexImage2DCHROMIUM
[23884:23884:0506/] : [GroupMarkerNotSet( )!:98FA32BE]GL ERROR :GL_OUT_OF_MEMORY : glTexStorage2DEXT: <- error from previous GL command
[23884:23884:0506/] : [GroupMarkerNotSet( )!:98FA32BE]GL ERROR :GL_OUT_OF_MEMORY : glTexStorage2DEXT:
[23884:23884:0506/] : Error: 5 for Command kTexStorage2DEXT
[23884:23884:0506/] : GLES2DecoderImpl: Context lost during MakeCurrent.
[23884:23884:0506/] : GLES2DecoderImpl: Context lost during MakeCurrent.
[23884:23884:0506/] : GLES2DecoderImpl: Context lost during MakeCurrent.
[23884:23884:0506/] : GLES2DecoderImpl: Context lost during MakeCurrent.
[23884:23884:0506/] : GLES2DecoderImpl: Context lost during MakeCurrent.
[23884:23884:0506/] : GLES2DecoderImpl: Context lost during MakeCurrent.
[23884:23884:0506/] : GLES2DecoderImpl: Context lost during MakeCurrent.
GpuProcessHostUIShim: The GPU process crashed!
[22633:22633:0506/] : InitializeSandbox() called with multiple threads in process gpu-process
[22633:22633:0506/] : FileDescriptorSet destroyed with unconsumed descriptors: 0/1
[22633:22633:0506/] : FileDescriptorSet destroyed with unconsumed descriptors: 0/1

Comment 26 by, May 6 2015

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.

Comment 27 by, Jun 30 2015

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.

Comment 28 by, Jul 1 2015

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

Comment 29 by, Jul 18 2015

Years goes, You won't fixes this bugs for us. 
Hate you, Google.

Comment 30 by, Jul 20 2015

My solution was, put 8GB RAM in my laptop, now google chrome uses 1~2gb with 10 or more tabs

Comment 31 by, Jul 20 2015

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.

Comment 32 by, Jul 21 2015

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, 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,

Comment 36 by, Nov 17 2015

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

Comment 37 by, Nov 17 2015

I think that the problem it is on Ubuntu 14.x because on Ubuntu 12.x I have not this problem

Comment 38 by, 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, Nov 17 2015


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, 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.

Comment 42 by, Nov 24 2015

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, 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

Comment 44 by, Mar 11 2016

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.

Comment 45 by, Mar 11 2016

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.

Comment 46 by, Apr 11 2016

Labels: Te-NeedsFurtherTriage

Comment 47 by, May 11 2016

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.

Comment 48 by, May 11 2016

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
63.9 KB View Download

Comment 49 by, Jul 15 2016

 Issue 588707  has been merged into this issue.

Comment 50 by, Aug 4 2016

Components: Internals
Labels: -Needs-Feedback -Te-NeedsFurtherTriage TE-NeedsTriageHelp

Comment 51 by, Sep 5 2016

Ubuntu GNOME 16.04.1 LTS 64 bit, 3 Gb RAM, same problem.

Comment 52 by, Dec 3 2016


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

Comment 54 by, Dec 9 2016

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

Comment 55 by, Dec 9 2016

Ubuntu, 16.04.1 64 bit, Also have 8GB Ram available, Chromium will use all RAM over time.

Comment 56 by, Dec 31 2016

xubuntu 16.04 64bit, chromium55.0.2883.87, same problem

Comment 57 by, Jan 10 2017

32GB RAM desktop, Chrome uses 20GB+ of it, with ~140 tabs.

Comment 58 Deleted

Comment 59 by, Jan 17 2017

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..

Comment 60 by, Jan 17 2017

List is growing in size. lots of people facing the issue yet no solution has been provided. what a shame!. At least a fix!.

Comment 61 by, Jan 24 2017

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 :(

Comment 62 by, Jan 24 2017

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

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.

Comment 63 by, Feb 1 2017

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

Comment 64 by, Feb 1 2017

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.

Comment 65 by, Feb 1 2017

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

Comment 66 by, Feb 1 2017

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:

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?

Comment 67 by, Feb 1 2017

> One other question: Is this on Windows 10?

Nevermind, I see it's linux in the metadata.

Comment 68 by, Feb 1 2017

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.

Comment 69 by, Feb 1 2017

I'll try that flag.

It's Ubuntu 16.04. I haven't noticed a leak this severe on Windows 10.

Comment 70 by, Feb 2 2017

It looks like the biggest leak is in gdbus:
Screenshot from 2017-02-02 10-04-42.png
151 KB View Download

Comment 71 by, Feb 2 2017

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.

Comment 72 by, Feb 2 2017

Also when I double click the "Thread: gdbus" entry it says "Cannot break down by stack frame any further".

Comment 73 by, Feb 3 2017

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 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.

Comment 74 by, Feb 3 2017

I also see my browser memory increase with each reload of and not go down after closing the window.

Comment 75 by, Feb 3 2017

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.

Comment 76 by, Feb 3 2017

I tried installing a lot of extensions but reloading the reddit site is not growing my browser process in my TOT build.

Comment 77 by, Feb 3 2017

I think I know what causes the gdbus leak.
I ran dbus-monitor, and noticed that each time I open, 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.

Comment 78 by, Feb 4 2017

I've exported all my passwords using this hidden feature:
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 79 by, Feb 5 2017

@Comment 78 by

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)

Comment 80 by, Feb 6 2017

Labels: -Type-Bug Type-Bug-Regression
Status: Started (was: Untriaged)
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

Comment 81 by, Feb 6 2017

Labels: -Needs-Feedback -TE-NeedsTriageHelp

Comment 82 by, Feb 6 2017

Labels: -Pri-2 Pri-1
Status: Assigned (was: Started)
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:
which is missing a g_list_free[_full]

Over to cfroussios@ for the fix.  We'll also want a merge to M56 and M57.
77.7 KB View Download

Comment 83 by, Feb 7 2017

> 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 for more

Comment 84 by, Feb 7 2017

g_list_free is not missing in KeyStorageLibsecret

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, where it is easier to see that we don't leak something ourselves. The only libsecret cleanup function I see is and it doesn't appear to fix it.

Comment 85 by, Feb 7 2017

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:

Comment 86 by, Feb 8 2017


Comment 87 by, Feb 8 2017

Comment 88 by, Jul 14 2017

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:

and the leak happens when I have a lot of passwords in the keyring, so the leak should be there somewhere.

Comment 89 by, Jul 14 2017

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.

Comment 90 by, Oct 27 2017

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 that leaks even with g_list_free_full, but maybe it'll fix the leak in Chrome.

Comment 91 by, Nov 10 2017

Project Member
The following revision refers to this bug:

commit a63b2ddd636c62a3fe3f5e46c6c951e9fce23993
Author: Christos Froussios <>
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-by: Vaclav Brozek <>
Commit-Queue: Christos Froussios <>
Cr-Commit-Position: refs/heads/master@{#515522}

Comment 92 by, Nov 10 2017

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.

Comment 93 by, Nov 10 2017

In src/components/os_crypt/, 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/ 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.

Comment 94 by, Nov 10 2017

Project Member
The following revision refers to this bug:

commit 707f4c1edd205d63db1c981891fe85feadfdab6d
Author: Colin Blundell <>
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:

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:
> Reviewed-by: Vaclav Brozek <>
> Commit-Queue: Christos Froussios <>
> Cr-Commit-Position: refs/heads/master@{#515522},

Change-Id: I99edccd11818f72168d1bd2d7de43ccd182e83e6
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  393395 
Reviewed-by: Colin Blundell <>
Commit-Queue: Colin Blundell <>
Cr-Commit-Position: refs/heads/master@{#515537}

Comment 95 by, Jan 17 2018

This is in fact a leak we're seeing in the wild, potentially causing GBs worth of memory leaks. See for one example.

At a guess, MSAN tests were failing because there are places where we mock SecretItems/Values with the wrong type, e.g.

There are also other locations where we fail to free the results from secret_service_search. I think the correct solution is to introduce a wrapper function for secret_service_search which always returned a ScopedC++ object which performs appropriate free-ing on destruction. Then, we also need to fix all the mocks.

Comment 96 by, Jan 17 2018

I tried the patch and it does not fully fix the leak. It appears there's also a leak in libsecret, my simple test program leaks too:

Comment 97 by, Jan 17 2018

Could we try to fix the leak in libsecret?  We would also need to bundle it since the fix would only roll out to newer linux distros.

Comment 98 by, Jan 17 2018

I haven't looked at the libsecret leak yet. At the very least, all of our calling code is incorrect as it fails to free the members of the GList returned by secret_service_search.

Comment 99 by, Jan 17 2018

re c#98: Is this leak the same as the one in c#82?

Comment 100 by, Jan 17 2018

Is there anything I can do to help contribute to fixing this? The main Chrome browser process has started leaking 15GB per day for me.

Comment 101 by, Jan 18 2018

Project Member
The following revision refers to this bug:

commit e3e1bc737140de3f68b2a40dfa1f51ad3815460c
Author: erikchen <>
Date: Thu Jan 18 16:31:29 2018

Fix memory leak in Linux libsecret wrapper.

secret_service_search_sync returns a glist, whose elements must also be freed.
The existing code did not do this. This CL creates a new SearchHelper to wrap
this call. The results are stored in the SearchHelper, whose destructor will
correctly free the elements.

This CL updates the key_storage_libsecret and native_backend_libsecret unittests
to return real GObjects from secret_service_search. The tear down steps now
check that the GObjects are correctly unreffed by the caller.

Bug:  801702 ,  393395 
Change-Id: I0dcac794d4d79499742aea6e7e42a99135367a51
Commit-Queue: Erik Chen <>
Reviewed-by: Thomas Anderson <>
Reviewed-by: Vasilii Sukhanov <>
Reviewed-by: Christos Froussios <>
Cr-Commit-Position: refs/heads/master@{#530162}

Comment 102 by, Jan 18 2018

Using heap profiling and this test page:

I've confirmed that we're no longer leaking libsecret-related objects. It's possible that there are other libsecret related leaks, but at least we're not hitting it on the test page.

Let's wait for Tuesday 1/23 dev release, and see if people are still having issues on that build. If not, we can close out this bug.

Comment 103 by, Jan 26 2018

Does anyone still have problems of the same nature on the latest dev release?

Comment 104 by, Feb 8 2018

I am happy to report that I the memory leak is gone; running chrome-unstable for almost two weeks now, no problems. Top shows no excessive memory usage either. Before that only a maximum of three days was possible.

Comment 105 by, Feb 8 2018

Status: Fixed (was: Assigned)

Comment 106 by, Nov 29

Showing comments 7 - 106 of 106 Older

Sign in to add a comment