Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1353855 - Possible memory leak in the glusterfs client after upgrade to v3.7.12
Summary: Possible memory leak in the glusterfs client after upgrade to v3.7.12
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: fuse
Version: mainline
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Raghavendra G
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 1353774 1353856
TreeView+ depends on / blocked
 
Reported: 2016-07-08 08:47 UTC by Raghavendra G
Modified: 2017-09-01 17:16 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1353774
: 1353856 (view as bug list)
Environment:
Last Closed: 2017-09-01 17:16:31 UTC
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)

Comment 1 Raghavendra G 2016-07-08 08:48:02 UTC
--- Additional comment from Raghavendra G on 2016-07-08 01:58:08 EDT ---

Seems like there is a leak in inodes:

# grep fuse.itable.active glusterdump.2460.dump.1467123831 | tail -1

[xlator.mount.fuse.itable.active.2904698]

As can be seen above there are 2904698 "active" inodes, which strongly points towards a leak.

regards,
Raghavendra

--- Additional comment from Raghavendra G on 2016-07-08 02:30:54 EDT ---

[raghu@unused 1353774]$ grep ia_type=1 ./glusterdump.2460.dump.1467123831 | wc -l
3457676
[raghu@unused 1353774]$ grep ia_type=2 ./glusterdump.2460.dump.1467123831 | wc -l
637

Seems like most of the inodes that leaked are regular files.

--- Additional comment from Raghavendra G on 2016-07-08 04:44:31 EDT ---

I think leak was introduced by http://review.gluster.org/#/c/11892/
for inodes on which "need-lookup" is set (typically the ones returned by readdirp), we call entry resolution even though loc->inode is set (as inode was already present in itable). However, fuse_resolve_entry_cbk assumes loc->inode is unset always, thereby overriding loc->inode with a new value without doing an unref.

regards,
Raghavendra

Comment 2 Csaba Henk 2017-09-01 17:16:31 UTC
Clone of bug 1353774 which is duplicate of bug 1294759 which is CLOSED CURRENTRELEASE. Closing this one too.


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