Bug 796591

Summary: valgrind log during graph change
Product: [Community] GlusterFS Reporter: Anush Shetty <ashetty>
Component: coreAssignee: Rajesh <rajesh>
Status: CLOSED NOTABUG QA Contact:
Severity: unspecified Docs Contact:
Priority: medium    
Version: mainlineCC: gluster-bugs, vagarwal, vbellur
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-05-10 06:27:21 UTC Type: ---
Regression: --- Mount Type: fuse
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Anush Shetty 2012-02-23 09:39:03 UTC
Description of problem: When fuse client process was run with valgrind and continuously changing the graph using volume set command, several definitely lost records were seen

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


How reproducible: Always


Actual results:



==5533==    by 0x4E633B6: __inode_create (inode.c:541)
==5533==    by 0x4E634BF: inode_new (inode.c:573)
==5533==    by 0x6FC7363: fuse_mkdir_resume (fuse-bridge.c:1253)
==5533==    by 0x6FC01A6: fuse_resolve_done (fuse-resolve.c:453)
==5533==    by 0x6FC027C: fuse_resolve_all (fuse-resolve.c:482)
==5533==    by 0x6FC016F: fuse_resolve (fuse-resolve.c:439)
==5533==    by 0x6FC0253: fuse_resolve_all (fuse-resolve.c:478)
==5533==    by 0x6FC02F6: fuse_resolve_continue (fuse-resolve.c:498)
==5533==    by 0x6FBFD55: fuse_resolve_parent (fuse-resolve.c:280)
==5533== 
==5533== 544 bytes in 2 blocks are possibly lost in loss record 168 of 354
==5533==    at 0x4C279F2: calloc (vg_replace_malloc.c:467)
==5533==    by 0x4011844: _dl_allocate_tls (dl-tls.c:300)
==5533==    by 0x5500B68: pthread_create@@GLIBC_2.2.5 (allocatestack.c:571)
==5533==    by 0x4E8F25E: syncenv_new (syncop.c:411)
==5533==    by 0x407FA2: main (glusterfsd.c:1601)
==5533== 
==5533== 960 bytes in 12 blocks are possibly lost in loss record 192 of 354
==5533==    at 0x4C279F2: calloc (vg_replace_malloc.c:467)
==5533==    by 0x4E7CE0A: __gf_default_calloc (mem-pool.h:84)
==5533==    by 0x4E7D2B3: __gf_calloc (mem-pool.c:138)
==5533==    by 0x50D5706: rpcclnt_cbk_program_register (rpc-clnt.c:1368)
==5533==    by 0x961AE55: client_init_rpc (client.c:2212)
==5533==    by 0x961B5DE: init (client.c:2382)
==5533==    by 0x4E49623: __xlator_init (xlator.c:365)
==5533==    by 0x4E4974D: xlator_init (xlator.c:388)
==5533==    by 0x4E8C1A2: glusterfs_graph_init (graph.c:300)
==5533==    by 0x4E8C957: glusterfs_graph_activate (graph.c:490)
==5533==    by 0x407C94: glusterfs_process_volfp (glusterfsd.c:1496)
==5533==    by 0x40C3CC: mgmt_getspec_cbk (glusterfsd-mgmt.c:1332)
==5533== 
==5533== 1,040 bytes in 8 blocks are definitely lost in loss record 203 of 354
==5533==    at 0x4C279F2: calloc (vg_replace_malloc.c:467)
==5533==    by 0x4E7CE0A: __gf_default_calloc (mem-pool.h:84)
==5533==    by 0x4E7D2B3: __gf_calloc (mem-pool.c:138)
==5533==    by 0x4E478E8: dict_allocate_and_serialize (dict.c:2711)
==5533==    by 0x9635516: client3_1_readdirp (client3_1-fops.c:5062)
==5533==    by 0x9619594: client_readdirp (client.c:1805)
==5533==    by 0x4E5B828: default_readdirp (defaults.c:1149)
==5533==    by 0x4E5B828: default_readdirp (defaults.c:1149)
==5533==    by 0x9C7656E: ioc_readdirp (io-cache.c:1430)
==5533==    by 0x4E5B828: default_readdirp (defaults.c:1149)
==5533==    by 0xA0A7D12: mdc_readdir (md-cache.c:1667)
==5533==    by 0xA2BFB3C: io_stats_readdir (io-stats.c:2319)
==5533== 
==5533== 1,042 (80 direct, 962 indirect) bytes in 2 blocks are definitely lost in loss record 205 of 354
==5533==    at 0x4C279F2: calloc (vg_replace_malloc.c:467)
==5533==    by 0x4E7CE0A: __gf_default_calloc (mem-pool.h:84)
==5533==    by 0x4E7D2B3: __gf_calloc (mem-pool.c:138)
==5533==    by 0x4E4263E: _dict_set (dict.c:275)
==5533==    by 0x4E4284A: dict_set (dict.c:324)
==5533==    by 0x4E4666C: dict_set_dynstr (dict.c:2134)
==5533==    by 0x4EA40D2: volume_option (graph.y:249)
==5533==    by 0x4EA35EE: yyparse (graph.y:76)
==5533==    by 0x4EA5040: glusterfs_graph_construct (graph.y:597)
==5533==    by 0x40BE3F: glusterfs_volfile_reconfigure (glusterfsd-mgmt.c:1211)
==5533==    by 0x40C2DE: mgmt_getspec_cbk (glusterfsd-mgmt.c:1318)
==5533==    by 0x50D41BE: rpc_clnt_handle_reply (rpc-clnt.c:796)
==5533== 
==5533== 1,120 bytes in 70 blocks are possibly lost in loss record 212 of 354
==5533==    at 0x4C28F9F: malloc (vg_replace_malloc.c:236)
==5533==    by 0x4E7CD86: __gf_default_malloc (mem-pool.h:72)
==5533==    by 0x4E7D3A9: __gf_malloc (mem-pool.c:164)
==5533==    by 0x9C78353: iov_dup (common-utils.h:262)
==5533==    by 0x9C7A02E: ioc_fault_cbk (page.c:489)
==5533==    by 0x9A691DF: ra_frame_unwind (page.c:449)
==5533==    by 0x9A69352: ra_frame_return (page.c:484)
==5533==    by 0x9A6388E: ra_readv (read-ahead.c:549)
==5533==    by 0x9C7A939: ioc_page_fault (page.c:630)
==5533==    by 0x9C73C0C: ioc_dispatch_requests (io-cache.c:1038)
==5533==    by 0x9C74B3E: ioc_readv (io-cache.c:1200)
==5533==    by 0x9E8B247: qr_readv (quick-read.c:1306)
==5533== 
==5533== 1,735 bytes in 447 blocks are definitely lost in loss record 232 of 354
==5533==    at 0x4C279F2: calloc (vg_replace_malloc.c:467)
==5533==    by 0x4E7CE0A: __gf_default_calloc (mem-pool.h:84)
==5533==    by 0x4E7D2B3: __gf_calloc (mem-pool.c:138)
==5533==    by 0x4E61F29: gf_strdup (mem-pool.h:130)
==5533==    by 0x4E631CD: __dentry_create (inode.c:499)
==5533==    by 0x4E63D1D: __inode_link (inode.c:815)
==5533==    by 0x4E63E2E: inode_link (inode.c:847)
==5533==    by 0x6FCA4C9: fuse_create_cbk (fuse-bridge.c:1651)
==5533==    by 0xA4CEF79: posix_acl_create_cbk (posix-acl.c:1171)
==5533==    by 0xA2B3CE9: io_stats_create_cbk (io-stats.c:1233)
==5533==    by 0xA0A4687: mdc_create_cbk (md-cache.c:1195)
==5533==    by 0x4E4DF5C: default_create_cbk (defaults.c:183)
==5533== 
==5533== 2,214 (360 direct, 1,854 indirect) bytes in 9 blocks are definitely lost in loss record 237 of 354
==5533==    at 0x4C279F2: calloc (vg_replace_malloc.c:467)
==5533==    by 0x4E7CE0A: __gf_default_calloc (mem-pool.h:84)
==5533==    by 0x4E7D2B3: __gf_calloc (mem-pool.c:138)
==5533==    by 0x4E4263E: _dict_set (dict.c:275)
==5533==    by 0x4E4284A: dict_set (dict.c:324)
==5533==    by 0x4E45CDD: dict_set_int16 (dict.c:1700)
==5533==    by 0x6FCB150: fuse_create (fuse-bridge.c:1811)
==5533==    by 0x6FD6712: fuse_thread_proc (fuse-bridge.c:3970)
==5533==    by 0x54FFEFB: start_thread (pthread_create.c:304)
==5533==    by 0x57F689C: clone (clone.S:112)
==5533== 
==5533== 2,706 (440 direct, 2,266 indirect) bytes in 11 blocks are definitely lost in loss record 247 of 354
==5533==    at 0x4C279F2: calloc (vg_replace_malloc.c:467)
==5533==    by 0x4E7CE0A: __gf_default_calloc (mem-pool.h:84)
==5533==    by 0x4E7D2B3: __gf_calloc (mem-pool.c:138)
==5533==    by 0x4E4263E: _dict_set (dict.c:275)
==5533==    by 0x4E4284A: dict_set (dict.c:324)
==5533==    by 0x4E45CDD: dict_set_int16 (dict.c:1700)
==5533==    by 0x6FCB096: fuse_create (fuse-bridge.c:1802)
==5533==    by 0x6FD6712: fuse_thread_proc (fuse-bridge.c:3970)
==5533==    by 0x54FFEFB: start_thread (pthread_create.c:304)
==5533==    by 0x57F689C: clone (clone.S:112)
==5533== 
==5533== 3,568 (448 direct, 3,120 indirect) bytes in 8 blocks are definitely lost in loss record 273 of 354
==5533==    at 0x4C279F2: calloc (vg_replace_malloc.c:467)
==5533==    by 0x4E7CE0A: __gf_default_calloc (mem-pool.h:84)
==5533==    by 0x4E7D2B3: __gf_calloc (mem-pool.c:138)
==5533==    by 0x4E41E63: get_new_dict_full (dict.c:67)
==5533==    by 0x4E41F03: dict_new (dict.c:98)
==5533==    by 0xA0A7ACF: mdc_readdir (md-cache.c:1661)
==5533==    by 0xA2BFB3C: io_stats_readdir (io-stats.c:2319)
==5533==    by 0xA4D134A: posix_acl_readdir (posix-acl.c:1415)
==5533==    by 0x6FCE93D: fuse_readdir_resume (fuse-bridge.c:2351)
==5533==    by 0x6FC01A6: fuse_resolve_done (fuse-resolve.c:453)
==5533==    by 0x6FC027C: fuse_resolve_all (fuse-resolve.c:482)
==5533==    by 0x6FC016F: fuse_resolve (fuse-resolve.c:439)

Comment 1 Rajesh 2012-02-24 07:22:51 UTC
isn't this the graph cleanup issue Du (Raghavendra Gowdappa) mailed us about?