The problem reappeared this afternoon after the daemon was up for about two
hours. I generated a series of cores on the iscsitgtd process if anybody is
interested (I have UMEM_LOGGING enabled). I can make them available on a
website or e-mail them (they are 17 megs each). The cores definitely show
something going on with memory leaks. In six minutes of uptime for the
iscsitgtd, I went from 302 to 324 leaks :
# mdb afterend3
Loading modules: [ ld.so.1 libumem.so.1 libavl.so.1 libc.so.1 libnvpair.so.1
libuutil.so.1 ]
> ::findleaks
CACHE LEAKED BUFCTL CALLER
0000000000484028 301 00000000005129a0 iscsi_full_feature+0x365
0000000000487368 1 0000000000517a80 libc.so.1`_thr_setup+0x5b
----------------------------------------------------------------------
Total 302 buffers, 19424 bytes
And, six minutes later....:
# mdb afterend4
Loading modules: [ ld.so.1 libumem.so.1 libavl.so.1 libc.so.1 libnvpair.so.1
libuutil.so.1 ]
> ::findleaks
CACHE LEAKED BUFCTL CALLER
0000000000484028 323 00000000005129a0 iscsi_full_feature+0x365
0000000000487368 1 0000000000517a80 libc.so.1`_thr_setup+0x5b
----------------------------------------------------------------------
Total 324 buffers, 20832 bytes
>
The /tmp/target_log file was altogether empty. I'm wondering if I should just
go ahead and install a new version of ON so as to ensure that I'm not simply
running down a problem that was already fixed in ON but not put back to S10U4.
-John
This message posted from opensolaris.org
_______________________________________________
storage-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/storage-discuss
