Hide Forgot
some definitely lost reports from valgrind on branch 3.2 ------- =19339== 25,387 (25,187 direct, 200 indirect) bytes in 1,556 blocks are definitely lost in loss record 17 of 18 ==19339== at 0x4A05414: calloc (vg_replace_malloc.c:397) ==19339== by 0x4C59246: __gf_default_calloc (mem-pool.h:83) ==19339== by 0x4C596F2: __gf_calloc (mem-pool.c:135) ==19339== by 0x710128E: pl_new_fdctx (posix.c:63) ==19339== by 0x7101451: pl_check_n_create_fdctx (posix.c:87) ==19339== by 0x710377D: pl_open_cbk (posix.c:464) ==19339== by 0x6EF037E: posix_acl_open_cbk (posix-acl.c:860) ==19339== by 0x6CDBE7B: posix_open (posix.c:2553) ==19339== by 0x6EF0626: posix_acl_open (posix-acl.c:891) ==19339== by 0x7103AEA: pl_open (posix.c:483) ==19339== by 0x731C03C: iot_open_wrapper (io-threads.c:713) ==19339== by 0x4C4D700: call_resume_wind (call-stub.c:2105) ==26620== 25,169 (25,137 direct, 32 indirect) bytes in 1,557 blocks are definitely lost in loss record 16 of 17 ==26620== at 0x4A05414: calloc (vg_replace_malloc.c:397) ==26620== by 0x4C59246: __gf_default_calloc (mem-pool.h:83) ==26620== by 0x4C596F2: __gf_calloc (mem-pool.c:135) ==26620== by 0x710128E: pl_new_fdctx (posix.c:63) ==26620== by 0x7101451: pl_check_n_create_fdctx (posix.c:87) ==26620== by 0x710377D: pl_open_cbk (posix.c:464) ==26620== by 0x6EF037E: posix_acl_open_cbk (posix-acl.c:860) ==26620== by 0x6CDBE7B: posix_open (posix.c:2553) ==26620== by 0x6EF0626: posix_acl_open (posix-acl.c:891) ==26620== by 0x7103AEA: pl_open (posix.c:483) ==26620== by 0x731C03C: iot_open_wrapper (io-threads.c:713) ==26620== by 0x4C4D700: call_resume_wind (call-stub.c:2105) ==26620== ==22481== 587 (555 direct, 32 indirect) bytes in 21 blocks are definitely lost in loss record 9 of 17 ==22481== at 0x4A05414: calloc (vg_replace_malloc.c:397) ==22481== by 0x4C59246: __gf_default_calloc (mem-pool.h:83) ==22481== by 0x4C596F2: __gf_calloc (mem-pool.c:135) ==22481== by 0x40381F: gf_strdup (mem-pool.h:129) ==22481== by 0x404BE3: parse_opts (glusterfsd.c:590) ==22481== by 0x3D920EC038: argp_parse (in /lib64/libc-2.10.2.so) ==22481== by 0x405E60: parse_cmdline (glusterfsd.c:1060) ==22481== by 0x406EEC: main (glusterfsd.c:1482) -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- fuse-log ==19350== 368 (216 direct, 152 indirect) bytes in 1 blocks are definitely lost in loss record 7 of 17 ==19350== at 0x4A05414: calloc (vg_replace_malloc.c:397) ==19350== by 0x4C59246: __gf_default_calloc (mem-pool.h:83) ==19350== by 0x4C596F2: __gf_calloc (mem-pool.c:135) ==19350== by 0x4C41567: __inode_create (inode.c:544) ==19350== by 0x4C429EE: __inode_table_init_root (inode.c:1153) ==19350== by 0x4C42D9F: inode_table_new (inode.c:1242) ==19350== by 0x62E4DF2: fuse_graph_setup (fuse-bridge.c:3320) ==19350== by 0x62E503E: notify (fuse-bridge.c:3366) ==19350== by 0x4C2A2A1: xlator_notify (xlator.c:1603) ==19350== by 0x4C3B976: default_notify (defaults.c:1228) ==19350== by 0x7E2468E: notify (io-stats.c:2620) ==19350== by 0x4C2A2A1: xlator_notify (xlator.c:1603) ==19350== ----------- stripe logs- ==26626== 4,645,496 (4,645,344 direct, 152 indirect) bytes in 107,547 blocks are definitely lost in loss record 16 of 17 ==26626== at 0x4A05414: calloc (vg_replace_malloc.c:397) ==26626== by 0x4C59246: __gf_default_calloc (mem-pool.h:83) ==26626== by 0x4C596F2: __gf_calloc (mem-pool.c:135) ==26626== by 0x4C42657: inode_path (inode.c:1056) ==26626== by 0x7145239: stripe_readdirp_cbk (stripe.c:3851) ==26626== by 0x6F0AB53: client3_1_readdirp_cbk (client3_1-fops.c:1939) ==26626== by 0x4E93FE9: rpc_clnt_handle_reply (rpc-clnt.c:741) ==26626== by 0x4E94348: rpc_clnt_notify (rpc-clnt.c:854) ==26626== by 0x4E90701: rpc_transport_notify (rpc-transport.c:919) ==26626== by 0x83E1B0A: socket_event_poll_in (socket.c:1647) ==26626== by 0x83E208E: socket_event_handler (socket.c:1762) ==26626== by 0x4C58B0B: event_dispatch_epoll_handler (event.c:794) ----
Shishir, Can you please take a look into the stripe leak? Post that, please assign this bug to KP for locks. Vijay
All the allocs seems to be freed appropriately. Please clean up the mnt point, drop the caches and check the valgrind results. Marking it as invalid.