View Incident:
http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=801095
Status : open Priority : 3
Assigned Engineer : dxm Submitter : dxm
*Modified User : lord *Modified User Domain : sgi.com
*Description :
xfs_repair -n phase7 seems to leak memory big time,
chewing up over 100Mb on sagan and causing processes
to get nuked.
==========================
ADDITIONAL INFORMATION (ADD)
From: lord@xxxxxxx (BugWorks)
Date: Sep 07 2000 08:15:50AM
==========================
Just for grins I used the glibc memory tracer on repair and
yes there is lots of leakage. The majority of it seems to come
from memory allocated at line 315 in libxfs/rdwr.c which is
the zone_zalloc call. There are only certain zones which get
called via zalloc, and based on the sizes which show up
(0x4c and 0x30) I would say that the culprit structures are
these
(gdb) print/x sizeof(xfs_buf_log_item_t)
$8 = 0x30
(gdb) print/x sizeof(xfs_inode_log_item_t)
$9 = 0x4c
I would ask how these items get freed in the case where
a transaction is committed, but is clean.
libxfs_trans_commit() will call xfs_trans_free_items for
a clean transaction, and trans_commited for a dirty one.
In the trans_commited case it ends up in the buf_item_done
and inode_item_done functions which free the memory, in the
xfs_trans_free_items case it ends up in xfs_trans_unlock_chunk
which does not do any freeing of this memory.
|