Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 403449 - www-client/chromium-19.0.1036.7 - chromium doesn't release memory if sandboxed and swap is used
Summary: www-client/chromium-19.0.1036.7 - chromium doesn't release memory if sandboxe...
Status: RESOLVED DUPLICATE of bug 413637
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: AMD64 Linux
: Normal normal (vote)
Assignee: Chromium Project
URL:
Whiteboard: ht-wanted
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-13 19:39 UTC by Alexandre
Modified: 2012-05-19 09:47 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Kernel config (config.gz,15.15 KB, application/x-gzip)
2012-02-17 18:50 UTC, Alexandre
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandre 2012-02-13 19:39:59 UTC
Chromium don't release memory when closing if sandboxed (default) and swap is used

Reproducible: Always

Steps to Reproduce:
1. start chromium (sandboxed by default)
2. fill the memory with any other app so the computer start swapping
3. try to quit, kill or kill -9 chromium

Actual Results:  
Chromium stays in D status and never release the memory used.

Expected Results:  
Chromium exit and release the memory used.

Don't happend if chromium start with --no-sandbox option.
Comment 1 Paweł Hajdan, Jr. (RETIRED) gentoo-dev 2012-02-15 10:19:36 UTC
(In reply to comment #0)
> Chromium don't release memory when closing if sandboxed (default) and swap is
> used

What version of www-client/chromium?

> Actual Results:  
> Chromium stays in D status and never release the memory used.

That's pretty bad, and may be kernel-related. What's your kernel version (uname -r)?

Also, is it a renderer process, main browser process or some other process?

You can determine that by looking at the browser's Task Manager and noting the PID of each process (and its type) before quitting.

Please post the contents of about:sandbox in your browser.
Comment 2 Alexandre 2012-02-15 18:32:19 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > Chromium don't release memory when closing if sandboxed (default) and swap is
> > used
> 
> What version of www-client/chromium?

www-client/chromium-19.0.1036.7

> 
> > Actual Results:  
> > Chromium stays in D status and never release the memory used.
> 
> That's pretty bad, and may be kernel-related. What's your kernel version (uname
> -r)?

3.2.6-gentoo

> 
> Also, is it a renderer process, main browser process or some other process?
> 
> You can determine that by looking at the browser's Task Manager and noting the
> PID of each process (and its type) before quitting.

Here is some free -h :

Start of the computer :
             total       used       free     shared    buffers     cached
Mem:          3,9G       965M       2,9G         0B        97M       501M
-/+ buffers/cache:       366M       3,5G
Swap:         5,0G         0B       5,0G

Start of chromium
             total       used       free     shared    buffers     cached
Mem:          3,9G       1,9G       1,9G         0B       103M       608M
-/+ buffers/cache:       1,2G       2,6G
Swap:         5,0G         0B       5,0G

After quitting chromium
             total       used       free     shared    buffers     cached
Mem:          3,9G       2,8G       1,1G         0B        21M       185M
-/+ buffers/cache:       2,6G       1,3G
Swap:         5,0G       191M       4,8G

ps aux | grep chrome
alex      7735  0.0  0.0      0     0 pts/1    D    19:51   0:00 [chrome_sandbox]
alex     10101  0.0  0.0      0     0 pts/1    D    19:53   0:00 [chrome_sandbox]

7735 and 10101 are not listed in the browser's Task Manager so I don't know who they are...

> 
> Please post the contents of about:sandbox in your browser.
Sandbox SUID	Oui
  Espaces de noms PID	Oui
  Espaces de noms réseau	Oui
Sandbox seccomp	Non
Sorry it's in french, but it seems OK
Comment 3 Alexandre 2012-02-16 12:54:49 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > Chromium don't release memory when closing if sandboxed (default) and swap is
> > > used
> > 
> > What version of www-client/chromium?
> 
> www-client/chromium-19.0.1036.7
> 
> > 
> > > Actual Results:  
> > > Chromium stays in D status and never release the memory used.
> > 
> > That's pretty bad, and may be kernel-related. What's your kernel version (uname
> > -r)?
> 
> 3.2.6-gentoo
> 
> > 
> > Also, is it a renderer process, main browser process or some other process?
> > 
> > You can determine that by looking at the browser's Task Manager and noting the
> > PID of each process (and its type) before quitting.
> 
> Here is some free -h :
> 
> Start of the computer :
>              total       used       free     shared    buffers     cached
> Mem:          3,9G       965M       2,9G         0B        97M       501M
> -/+ buffers/cache:       366M       3,5G
> Swap:         5,0G         0B       5,0G
> 
> Start of chromium
>              total       used       free     shared    buffers     cached
> Mem:          3,9G       1,9G       1,9G         0B       103M       608M
> -/+ buffers/cache:       1,2G       2,6G
> Swap:         5,0G         0B       5,0G
> 

I forgot to say that before quitting chromium, I used it while emerging some things

> After quitting chromium
>              total       used       free     shared    buffers     cached
> Mem:          3,9G       2,8G       1,1G         0B        21M       185M
> -/+ buffers/cache:       2,6G       1,3G
> Swap:         5,0G       191M       4,8G
> 
> ps aux | grep chrome
> alex      7735  0.0  0.0      0     0 pts/1    D    19:51   0:00
> [chrome_sandbox]
> alex     10101  0.0  0.0      0     0 pts/1    D    19:53   0:00
> [chrome_sandbox]
> 
> 7735 and 10101 are not listed in the browser's Task Manager so I don't know who
> they are...
> 
> > 
> > Please post the contents of about:sandbox in your browser.
> Sandbox SUID    Oui
>   Espaces de noms PID    Oui
>   Espaces de noms réseau    Oui
> Sandbox seccomp    Non
> Sorry it's in french, but it seems OK
Comment 4 Alexey Dobriyan 2012-02-17 13:21:12 UTC
$ cat /proc/$PID/wchan

or even better

$ cat /proc/$PID/stack

where PID -- PID of a process in D-state.
Comment 5 Alexey Dobriyan 2012-02-17 13:22:36 UTC
Also attach .config just in case

/boot/config-$(uname -r)

or

/proc/config.gz
Comment 6 Alexandre 2012-02-17 18:50:21 UTC
(In reply to comment #4)
> $ cat /proc/$PID/wchan

0

> 
> or even better
> 
> $ cat /proc/$PID/stack

I don't have this

> 
> where PID -- PID of a process in D-state.
Comment 7 Alexandre 2012-02-17 18:50:54 UTC
Created attachment 302287 [details]
Kernel config
Comment 8 Alexey Dobriyan 2012-02-20 10:40:10 UTC
(In reply to comment #6)
> (In reply to comment #4)
> > $ cat /proc/$PID/wchan
> 
> 0

hmm

Do you see /proc/$PID/syscall ?
Comment 9 Paweł Hajdan, Jr. (RETIRED) gentoo-dev 2012-02-20 18:16:29 UTC
Are you able to reproduce with 19.0.1041.0? I'm not asking this blindly, it seems similar to an upstream bug claimed to be fixed (sorry I have no link to it).
Comment 10 Alexandre 2012-02-20 21:33:36 UTC
(In reply to comment #9)
> Are you able to reproduce with 19.0.1041.0? I'm not asking this blindly, it
> seems similar to an upstream bug claimed to be fixed (sorry I have no link to
> it).

yes...

(In reply to comment #8)
> (In reply to comment #6)
> > (In reply to comment #4)
> > > $ cat /proc/$PID/wchan
> > 
> > 0
> 
> hmm
> 
> Do you see /proc/$PID/syscall ?

yes, it contains the following :
231 0x0 0x3c 0x0 0x31139a5210 0xe7 0xffffffffffffff80 0x7fff1b2ab7d0 0x31136b1d18
Comment 11 Alexey Dobriyan 2012-02-20 23:14:35 UTC
231 is sys_exit_group()
Comment 12 Alexandre 2012-02-21 07:05:31 UTC
(In reply to comment #11)
> 231 is sys_exit_group()

which means what ?
Comment 13 Paweł Hajdan, Jr. (RETIRED) gentoo-dev 2012-05-17 10:15:29 UTC
Is this possibly a duplicate of bug #413637 ? Please test with >=chromium-19.0.1084.46-r1
Comment 14 Alexandre 2012-05-19 09:47:50 UTC
(In reply to comment #13)
> Is this possibly a duplicate of bug #413637 ? Please test with
> >=chromium-19.0.1084.46-r1

Doesn't seems to happend anymore.
Thanks.

*** This bug has been marked as a duplicate of bug 413637 ***