Bug 765403 (GLUSTER-3671) - nightly valgrind - definitely lost blocks
Summary: nightly valgrind - definitely lost blocks
Keywords:
Status: CLOSED NOTABUG
Alias: GLUSTER-3671
Product: GlusterFS
Classification: Community
Component: posix
Version: 3.3-beta
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: ---
Assignee: shishir gowda
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-09-30 07:02 UTC by Lakshmipathi G
Modified: 2013-12-09 01:27 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:


Attachments (Terms of Use)

Description Lakshmipathi G 2011-09-30 07:02:32 UTC
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)
----

Comment 1 Vijay Bellur 2011-10-10 03:06:07 UTC
Shishir,

Can you please take a look into the stripe leak? Post that, please assign this bug to KP for locks.

Vijay

Comment 2 shishir gowda 2011-10-11 01:39:57 UTC
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.


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