73.0.3641.0 memory leak both during build and run

142 views
Skip to first unread message

t dance

unread,
Dec 19, 2018, 2:47:49 PM12/19/18
to Chromium-dev
73.0.3641.0 runing now
But during building I needed to interrupt [Ctrl-C] and reboot many times (third-party/clang++ ?)
Running Chromium needs reboot once-twice a day because memory exhausted

bruce...@chromium.org

unread,
Dec 28, 2018, 8:22:29 PM12/28/18
to Chromium-dev
For memory leaks while Chrome is running please go to crbug.com and file a bug giving enough repro steps for us to be able to investigate.

For memory leaks while building Chrome this is the appropriate forum. However you will need to give more information. What OS are you running? How much memory do you have? What are the symptoms? Building Chrome efficiently requires a lot of memory (I would recommend 32+ GB, but 16 GB is probably fine) but it shouldn't cause memory leaks. In particular, since all of the processes involved in building Chrome go away when the build completes there should be nothing left to hold on to memory, so a leak should be impossible. That said, I have encountered bugs in monitoring software that can lead to zombie processes and from there to memory leaks, but that was only leaking about 100 MB per build, and has since been fixed.

TL;DR - look for processes with excessive handle counts and try to figure out where the memory is going, because building Chrome doesn't normally leak memory. And file a detailed bug for any memory leaks in the browser.

t dance

unread,
Dec 29, 2018, 5:36:32 AM12/29/18
to Chromium-dev
@bruce
Thanks for the reply. I posted here only to find confirmation.
So for runtime leaks I  need to log every step I make
For build leak I need more memory? 71.0.3547.0 did build on my 4G+6G swap without rebooting
I'll try with a newer snapshot

Bruce Dawson

unread,
Dec 29, 2018, 11:48:21 AM12/29/18
to dnts...@gmail.com, Chromium-dev
Building Chrome with 4G of RAM is quite borderline. With a fast SSD and enough swap it might work, but it's really not supported. It's not a leak, it's just that build steps like linking take a lot of memory. Sorry.  Building with symbol_level=1 will probably help, but then you can't do source-level debugging.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to a topic in the Google Groups "Chromium-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-dev/g8M7cpguwc4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/e481e453-3d20-43c8-b4ad-ece7efcc03ac%40chromium.org.

t dance

unread,
Dec 29, 2018, 3:30:49 PM12/29/18
to Chromium-dev, dnts...@gmail.com
I thought those memory exhaustions were related, So only runtime leak is true. These were my configs for 4G:
enable_nacl = false
ffmpeg_branding = "Chrome"
is_debug = false
proprietary_codecs = true
remove_webcore_debug_symbols = true
use_sysroot = false
use_system_freetype = true
use_system_harfbuzz = true
use_system_lcms2 = true
use_system_libdrm = true
use_system_libjpeg = true
use_system_libpng = true 
use_system_zlib = true

Bruce Dawson

unread,
Dec 30, 2018, 8:21:58 PM12/30/18
to dnts...@gmail.com, Chromium-dev
That's a lot of configuration options - I'm curious as to why there are so many.

Consider adding symbol_level=1 in order to reduce the memory requirements when linking. Or, consider getting more memory. Chromium is one of the largest applications in the world and building it on a 4 GB machine is really not supported.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to a topic in the Google Groups "Chromium-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-dev/g8M7cpguwc4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chromium-dev...@chromium.org.

t dance

unread,
Dec 31, 2018, 2:21:59 AM12/31/18
to Chromium-dev, dnts...@gmail.com
On Monday, December 31, 2018 at 2:21:58 AM UTC+1, Bruce Dawson wrote:
That's a lot of configuration options - I'm curious as to why there are so many.

$  gn args out/Default --list

Consider adding symbol_level=1 in order to reduce the memory requirements when linking. Or, consider getting more memory. Chromium is one of the largest applications in the world and building it on a 4 GB machine is really not supported

I think symbol_level is already set to 1 by is_debug = false

I have submitted a bug report at http://crbug.com/ And the reply is that it had been patched. So I'll do a new build

Bruce Dawson

unread,
Dec 31, 2018, 7:47:49 PM12/31/18
to t dance, Chromium-dev
I know that there are a lot of gn args. I was curious about why you are specifying so many. Usually I just specify debug on/off and component build on/off, or maybe I'll set enable_nacl=false or remove_webcore_debug_symbols=true to improve build speeds. Every gn arg that you set increases the odds that you are building an untested configuration so I don't recommend setting a lot without reasons. Anyway, I was just curious.

It looks like symbol_level does indeed default to 1 for non-debug builds on Linux, but on Windows the default is always 2, so it depends what platform you are building for.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to a topic in the Google Groups "Chromium-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-dev/g8M7cpguwc4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chromium-dev...@chromium.org.

t dance

unread,
Jan 1, 2019, 8:00:05 AM1/1/19
to Chromium-dev, dnts...@gmail.com
@Bruce Dawson
Yes it is a LFS system
ffmpeg_branding = "Chrome"
proprietary_codecs = true
  are to enable missing codecs
use_sysroot = false
use_system_freetype = true
use_system_harfbuzz = true
use_system_lcms2 = true
use_system_libdrm = true
use_system_libjpeg = true
use_system_libpng = true 
use_system_zlib = true
 are for faster compile and link. I did it since my first 43.0.2336. Some didn't work but those are fixed now

t dance

unread,
Jan 2, 2019, 3:31:47 PM1/2/19
to Chromium-dev, dnts...@gmail.com
73.0.3658.0 built. But I still suspect memory usage:
1. starting PC and login. Mem usage 31.6%
2. start and close chromium. Mem 32.2%
3. again. Mem 32.3%
4. again. with reloading start page a few times. Mem 37.3%
5, just start and close chromium. Mem. 37.5%
6. start chromium and openig wikipedia pages in multiple tabs then closing chromium. Mem 43.7%

Bruce Dawson

unread,
Jan 2, 2019, 4:15:29 PM1/2/19
to t dance, Chromium-dev
You'll need to dig deeper into what that memory usage number actually means. Memory is extremely complicated because there are so many different measurements (working set, committed pages, physical memory in use, swap used, etc.) and it is not always clear which one is relevant.

Some memory measurements include memory used for the OS disk cache. This memory is "in use" but can be discarded at a moments notice if it is needed for something else. This memory will often increase over time but this is a good thing because cached data is faster than going to the disk.

That said, the steps you describe do not (I don't think) indicate a memory leak in Chromium. When Chromium shuts down then all of its memory is freed. This is guaranteed by the operating system. Chromium cannot be holding on to memory when it isn't even running. Thus, if the amount of memory in use increases at the various checkpoints where Chrome is not running then it is-not and cannot be a Chromium memory leak. It may be data cached by the OS, data from background programs, or something else, but it's not a Chromium memory leak.

If you're really interested in why memory usage is reported as increasing then you will have to learn what that number represents and then find tools to tell you exactly where it is going.

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to a topic in the Google Groups "Chromium-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/chromium.org/d/topic/chromium-dev/g8M7cpguwc4/unsubscribe.
To unsubscribe from this group and all its topics, send an email to chromium-dev...@chromium.org.

t dance

unread,
Jan 3, 2019, 2:15:41 AM1/3/19
to Chromium-dev, dnts...@gmail.com
@Bruce Dawson
I tested a few other gtk-apps (evince evolution gimp vim) and after starting and closing them then evolution leave a small footprint in memory 0.4%. Could be caused by mariadb, tmpfs or by disk cache. Because other users don't have issues with new Chromium i guess that there is still a memory leak in Gnome-3.30.2. Which can only be discovered by using Chrmium because it uses many PIDs. I hope other users of Gnome-3.30.2 can confirm this

Reply all
Reply to author
Forward
0 new messages