Home
openafs@conference.openafs.org
Thursday, July 3, 2014< ^ >
Room Configuration
Room Occupants

GMT+0
[00:00:04] ktdreyer joins the room
[00:00:30] ktdreyer leaves the room
[09:12:28] squinney joins the room
[09:44:49] squinney leaves the room
[09:49:17] squinney joins the room
[11:28:29] squinney joins the room
[11:31:04] ktdreyer joins the room
[12:28:12] squinney leaves the room
[13:36:19] ktdreyer leaves the room
[13:37:12] ktdreyer joins the room
[14:27:27] kaduk joins the room
[14:55:33] <kaduk> Any thoughts about that afs_PutConn refcount imbalance in RT #131885?
[14:55:33] gorgo leaves the room
[14:55:33] squinney leaves the room
[15:19:42] <Jeffrey Altman> I hate refcnt erros
[15:21:12] <Jeffrey Altman> from the perspective of identifying it, knowing the pattern of RPCs that were being performed prior to the error would be helpful.
[15:21:32] <Jeffrey Altman> its an undercount which is much easier to track down than a leak.
[15:21:39] <kaduk> Indeed.
[15:22:44] <kaduk> It struck my attention because when I was debugging the call refcount issue on master, my valgrind traces seemed to be claiming that there were leaks of connections as well as calls, but the commit I made has empirically plugged the memory leak I was seeing.  Perhaps my test servers don't see the same load pattern as the reporter of this new issue, of course.
[15:23:40] <Jeffrey Altman> I wasted many vacations tracking down refcnt errors in the windows cache manager.   I don't envy the person that is going to hunt for this one.    You will see that the windows cm has a special build mode to generate logging for refcnt changes so that identifying where the problems are becomes possible.
[15:25:11] <kaduk> *nods*.  I don't think what I hacked in for the rx_calls was quite good enough to leave in the tree (so I didn't submit it).
[15:26:08] <mvita> that's cool, jaltman.  I like your lock hierarchy enforcement in windows CM as well - I'd really like to get something like that into the unix CM some day.
[15:26:55] <kaduk> I found at least one unix CM locking issue with FreeBSD's WITNESS kernel option that does lock order tracking.
[15:27:07] <kaduk> I think it does not track all of the lock types that we use, though.
[15:27:31] <mvita> yea, that's the trouble, some of our locks are not native locks
[15:28:07] meffie joins the room
[16:00:28] <kaduk> I guess the number -32768 was a little suspicious, but the negative number in twos-complement is not actually a single bit set.
[17:23:02] meffie leaves the room
[19:16:33] ktdreyer leaves the room
[22:32:11] kaduk leaves the room
[23:03:34] ballbery leaves the room
[23:07:40] ballbery joins the room
[23:49:30] ballbery leaves the room
Powered by ejabberd Powered by Erlang Valid XHTML 1.0 Transitional Valid CSS!