Bug 790709 - valgrind report when fuse client is mounted with attribute-timeout=1
Summary: valgrind report when fuse client is mounted with attribute-timeout=1
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: GlusterFS
Classification: Community
Component: fuse
Version: mainline
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: ---
Assignee: Raghavendra Bhat
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-02-15 08:59 UTC by Anush Shetty
Modified: 2013-07-24 17:37 UTC (History)
3 users (show)

Fixed In Version: glusterfs-3.4.0
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-07-24 17:37:52 UTC
Regression: ---
Mount Type: fuse
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)
Valgrind log file. (97.80 KB, text/x-log)
2012-02-15 08:59 UTC, Anush Shetty
no flags Details

Description Anush Shetty 2012-02-15 08:59:20 UTC
Created attachment 562166 [details]
Valgrind log file.

Description of problem: When fuse client with mounting with  attribute-timeout=1, several definitely lost records were seen in the valgrind log.


Version-Release number of selected component (if applicable): 3.3.0qa22

Attaching the valgrind log file.

Comment 1 Amar Tumballi 2012-07-11 05:33:07 UTC
considering there are so much of new code added in the stack, need a fresh run of valgrind. Need to check if the logs are valid now or not.

Comment 2 Raghavendra Bhat 2012-11-30 06:42:59 UTC
It seems the glusterfs process ran via valgrind was stopped when some tests were still running. If tests are running and files are present in in the volume, then killing the process without stopping all the tests and without doing dropping caches will show more memory loss. Still some leaks present are handled by the patch http://review.gluster.org/#change,4250.

==13233== 33,287,140 (5,826,016 direct, 27,461,124 indirect) bytes in 43,625 blocks are definitely lost in loss record 495 of 501
==13233==    at 0x4C279F2: calloc (vg_replace_malloc.c:467)
==13233==    by 0x4E7B9C6: __gf_default_calloc (mem-pool.h:84)
==13233==    by 0x4E7BE6F: __gf_calloc (mem-pool.c:138)
==13233==    by 0x4E77B4D: __fd_create (fd.c:506)
==13233==    by 0x4E77BFB: fd_create (fd.c:529)
==13233==    by 0x800C210: fuse_open_resume (fuse-bridge.c:1814)
==13233==    by 0x800196B: fuse_resolve_done (fuse-resolve.c:455)
==13233==    by 0x8001A41: fuse_resolve_all (fuse-resolve.c:484)
==13233==    by 0x8001934: fuse_resolve (fuse-resolve.c:441)
==13233==    by 0x8001A18: fuse_resolve_all (fuse-resolve.c:480)
==13233==    by 0x8001ABB: fuse_resolve_continue (fuse-resolve.c:500)
==13233==    by 0x8001670: fuse_resolve_inode (fuse-resolve.c:330)
==13233== 
==13233==    at 0x4C279F2: calloc (vg_replace_malloc.c:467)
==13233==    by 0x4E7B9C6: __gf_default_calloc (mem-pool.h:84)
==13233==    by 0x4E7BE6F: __gf_calloc (mem-pool.c:138)
==13233==    by 0x4E623D6: __inode_create (inode.c:541)
==13233==    by 0x4E624DF: inode_new (inode.c:573)
==13233==    by 0x800B8BD: fuse_create_resume (fuse-bridge.c:1713)
==13233==    by 0x800196B: fuse_resolve_done (fuse-resolve.c:455)
==13233==    by 0x8001A41: fuse_resolve_all (fuse-resolve.c:484)
==13233==    by 0x8001934: fuse_resolve (fuse-resolve.c:441)
==13233==    by 0x8001A18: fuse_resolve_all (fuse-resolve.c:480)
==13233==    by 0x8001ABB: fuse_resolve_continue (fuse-resolve.c:500)
==13233==    by 0x8001544: fuse_resolve_parent (fuse-resolve.c:279)

Comment 3 Vijay Bellur 2012-12-04 20:14:44 UTC
CHANGE: http://review.gluster.org/4250 (fix memory leaks) merged in master by Anand Avati (avati)


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