Jonathan,
How I can use print for my application?
> *cpqary3_state::walk softstate|::print -at cpqary3_t drvr_replyq
ffffff01d51948a0 cpqary3_drvr_replyq_t *drvr_replyq = 0xffffff01d7f1cf10
> 0xffffff01d7f1cf10::print -at cpqary3_drvr_replyq_t phyctgp
ffffff01d7f1cf3a struct cpqary3_phyctg *phyctgp = 0xffffff01d7109cd0
These buffers are allocated by kmem_zalloc(x,KM_NOSLEEP),
cpqary3p->drvr_replyq = (cpqary3_drvr_replyq_t *)
kmem_zalloc(sizeof (cpqary3_drvr_replyq_t),KM_NOSLEEP);
cpqary3_phyctgp = (cpqary3_phyctg_t *)
kmem_zalloc(sizeof (cpqary3_phyctg_t), KM_NOSLEEP);
cpqary3p->drvr_replyq->phyctgp = cpqary3_phyctgp;
Thanks!
Valdemar
________________________________
From: mdb-discuss-boun...@opensolaris.org
[mailto:mdb-discuss-bounces at opensolaris.org] On Behalf Of ext Colin Yi
Sent: Friday, September 11, 2009 12:04 AM
To: Jonathan Adams
Cc: mdb-discuss at opensolaris.org
Subject: Re: [mdb-discuss] ::findleaks issue?
Hi Adams,
Thanks for the response.
The coredump file was losted since I reinstalled this system, But I
recreated a new one
and copied the related results here:
> ::findleaks
CACHE LEAKED BUFCTL CALLER
ffffff01cb02b458 1 ffffff01d80baa20 cpqary3_init_ctlr+0x16c
ffffff01cb030018 1 ffffff01da6d8668 impl_acc_hdl_alloc+0x34
ffffff01cb030018 1 ffffff01d8149808 impl_acc_hdl_alloc+0x34
ffffff01cb02b018 1 ffffff01da3cf138 impl_acc_hdl_alloc+0x4a
ffffff01cb02b018 1 ffffff01d8000800 impl_acc_hdl_alloc+0x4a
ffffff01cb02e018 1 ffffff01d9fbb388 impl_acc_hdl_alloc+0x64
ffffff01cb02e018 1 ffffff01d51673e0 impl_acc_hdl_alloc+0x64
ffffff01d7079458 1 ffffff01d8149070 rootnex_coredma_allochdl+0x5c
ffffff01d7079458 1 ffffff01da6cc548 rootnex_coredma_allochdl+0x5c
ffffff01cb02e898 1 ffffff01ea88b590 scsi_hba_probe+0x5c
ffffff01cb02f458 1 ffffff01da37ae08 uhci_polled_create_tw+0x2a
------------------------------------------------------------------------
Total 11 buffers, 6448 bytes
> ffffff01d80baa20::bufctl -v
ADDR BUFADDR TIMESTAMP THREAD
CACHE LASTLOG CONTENTS
ffffff01d80baa20 ffffff01d7109cd0 2f04faa1db fffffffffbc2efe0
ffffff01cb02b458 ffffff01cd0c1800 ffffff01d14cee10
kmem_cache_alloc_debug+0x283
kmem_cache_alloc+0xa9
kmem_zalloc+0x6a
cpqary3_init_ctlr+0x16c
cpqary3_init_ctlr_resource+0x22
cpqary3_attach+0x149
devi_attach+0x80
attach_node+0x95
i_ndi_config_node+0xa5
i_ddi_attachchild+0x40
devi_attach_node+0xac
devi_config_one+0x2f3
ndi_devi_config_one+0xb4
resolve_pathname+0x164
ddi_pathname_to_dev_t+0x1f
> *cpqary3_state::walk softstate|::print -at cpqary3_t drvr_replyq
ffffff01d51948a0 cpqary3_drvr_replyq_t *drvr_replyq = 0xffffff01d7f1cf10
> 0xffffff01d7f1cf10::print -at cpqary3_drvr_replyq_t phyctgp
ffffff01d7f1cf3a struct cpqary3_phyctg *phyctgp = 0xffffff01d7109cd0
These buffers are allocated by kmem_zalloc(x,KM_NOSLEEP),
cpqary3p->drvr_replyq = (cpqary3_drvr_replyq_t *)
kmem_zalloc(sizeof (cpqary3_drvr_replyq_t),KM_NOSLEEP);
cpqary3_phyctgp = (cpqary3_phyctg_t *)
kmem_zalloc(sizeof (cpqary3_phyctg_t), KM_NOSLEEP);
cpqary3p->drvr_replyq->phyctgp = cpqary3_phyctgp;
> 0xffffff01d7f1cf10::whatis
ffffff01d7f1cf10 is ffffff01d7f1cf10+0, bufctl ffffff01d8014148
allocated from
kmem_alloc_56
Thanks,
Colin
Jonathan Adams Wrote:
On Wed, Sep 09, 2009 at 12:35:33PM +0800, Colin Yi wrote:
From the above results, We know for the first leak the
buffer address
is 0xffffff01d710ad18
*cpqary3_state::walk softstate|::print -at
cpqary3_t drvr_replyq
ffffff01d51948a0 cpqary3_drvr_replyq_t *drvr_replyq =
0xffffff01d7f11e70
0xffffff01d7f11e70::print -at
cpqary3_drvr_replyq_t phyctgp
ffffff01d7f11e9a struct cpqary3_phyctg *phyctgp =
0xffffff01d710ad18
Following the global variable "cpqary3_state", I found
there is a pointer
"phyctgp"
is pointer to the leaked buf address since the
cpqary3_state->phyctgp->phyctgp==0xffffff01d710ad18
Since buffer(0xffffff01d710ad18) is point by pointer
cpqary3_state->phyctgp->phyctgp
Why ::findleaks think this buffer is a mem leak?
How are these buffers allocated? (in particular, how is the
cpqary3_drvr_replyq_t allocated?)
What does:
0xffffff01d7f11e70::whatis
output?
Cheers,
- jonathan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/mdb-discuss/attachments/20090911/5f4c8cc3/attachment-0001.html>
