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/90b78c23/attachment.html>
