Bug 1331779 - Huge leaks in caribou (and nautilus) when adding/removing block devices [NEEDINFO]
Summary: Huge leaks in caribou (and nautilus) when adding/removing block devices
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: caribou
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Parag Nemade
QA Contact: QE Internationalization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-29 13:34 UTC by Marian Csontos
Modified: 2020-04-06 07:12 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-06 07:12:07 UTC
Target Upstream Version:
pnemade: needinfo? (mcsontos)


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1331762 0 unspecified CLOSED Huge leaks in nautilus (and caribou) when adding/removing block devices 2021-02-22 00:41:40 UTC

Internal Links: 1331762

Description Marian Csontos 2016-04-29 13:34:15 UTC
Description of problem:
Huge leaks in caribou (and nautilus) when adding/removing block devices.

I was testing creating many LVs on a system with running gnome session. I expected memory to be stressed a bit but did not expect caribou (and nautilus) consuming 2.86GB (and 6.46GB) or RAM.

Until now I did not know there is a caribou. Now I do know, but do not understand why a "text entry and UI navigation" would have anything to do with disks. But I am sure it should not consume nearly 3GB of RAM.

Version-Release number of selected component (if applicable):
Running RHEL7.2:
caribou-0.4.16-1.el7.x86_64
nautilus-3.14.3-7.el7.x86_64

How reproducible:
100%

Steps to Reproduce:
1. for i in $(seq 1500); do lvcreate -kn -s $VG/$THINLV; done

Actual results:
Wasted 9+ GB or RAM.

Expected results:
There should be some saner limit what the application consumes.
Especially when doing "nothing".

Additional info:

> top - 13:22:11 up 26 days,  2:29,  8 users,  load average: 0.18, 0.29, 0.37
> Tasks: 3776 total,   1 running, 3770 sleeping,   5 stopped,   0 zombie
> %Cpu(s): 27.9 us,  4.3 sy,  0.2 ni, 67.6 id,  0.1 wa,  0.0 hi,  0.0 si,  0.0 st
> KiB Mem : 15889328 total,   165116 free, 14954932 used,   769280 buff/cache
> KiB Swap:  8388604 total,  1828152 free,  6560452 used.   204764 avail Mem 
> 
>   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
> 19891 mrtianc   20   0 8001360 6.462g   1248 S   0.0 42.6  24:14.70 nautilus
> 19721 mrtianc   20   0 3839744 2.866g    904 S   0.0 18.9  14:04.27 caribou
> 25805 mcsontos  20   0 2028732 658272  15216 S   0.0  4.1   9:00.27 firefox

Even deactivating LVs causes both nautilus and caribou leaking a lot.

After restarting gnome, the programs were fine, until I started manipulating the LVs.
After deactivating 1000LVs it now looks like this:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                          
28616 mrtianc   20   0 2616316 1.698g  16968 S   0.0 11.2   5:59.90 nautilus                                                         
20996 mcsontos  20   0 2597992 871032  31120 S   0.7  5.5 206:29.34 firefox                                                          
27886 mrtianc   20   0 1314972 751520   5044 S   0.0  4.7   2:58.94 caribou

Nautilus and caribou were running at full speed for 6 minutes, nautilus consuming 100% CPU, and caribou "only" 50%.

Reactivating all these 1000 LVs gets both applications running again.

The fact deactivating devices is causing memory going up suggests there is a huge leak - over 1MB in nautilus and 0.7MB in caribou for each activated/deactivated LV.

Comment 1 Marian Csontos 2016-04-29 13:46:25 UTC
Activating the volumes back the leaks are much worse: 4M in nautilus and 1.8M in caribou per LV.

> 28616 mrtianc   20   0 6490804 5.334g   3052 S   0.0 35.2  20:20.58 nautilus
> 27886 mrtianc   20   0 3109652 2.407g    908 S   0.0 15.9  10:06.78 caribou

Comment 3 Yan Li 2016-10-26 19:59:57 UTC
I might be having a similar/related problem here although the trigger is a little different. I added just one LVM and saw the caribou process eating around 80% CPU while I was reading/writing that LVM. This might be coincident but the caribous process slowly stopped hogging CPU after the read/write stopped. Also I didn't see a memory leak, it was just hogging CPU and slowing down everything else.

Comment 4 Parag Nemade 2018-09-19 12:57:13 UTC
Can anyone re-test and provide if this bug is still reproducible? Also note that Caribou is not present in RHEL-7.6 as it is replaced by gnome-shell.

Comment 5 Jens Petersen 2019-11-04 04:47:18 UTC
Given that this package is no longer maintained upstream or used in GNOME Shell, I think it makes sense to close this bug now.

Comment 6 Jens Petersen 2020-02-12 04:06:15 UTC
Is there a corresponding bug for Nautilus?

Do this kind of issue still happen in RHEL 7.7+?

Comment 7 Jens Petersen 2020-02-12 04:07:48 UTC
(In reply to Jens Petersen from comment #6)
> Is there a corresponding bug for Nautilus?

Nvm I see the bug linked above.


Note You need to log in before you can comment on or make changes to this bug.