[01:18:23] --- Russ has left: Disconnected [02:26:28] --- Simon Wilkinson has become available [02:39:36] --- Simon Wilkinson has left [03:39:50] --- SecureEndpoints has left: Replaced by new connection [07:31:05] --- dev-zero@jabber.org has become available [08:05:34] --- SecureEndpoints has become available [08:05:56] --- dev-zero@jabber.org has left [09:09:28] Please review /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/rx-qcount-2.patch This patch adds additional debugging information to the rx library when build with -DDEBUG that permits (on Windows) most of the rx_call and rx_packet object state to be dumped to a file for analysis. The two most important parts of the patch create linked lists containing all of the allocated objects and queue counters (rq, tq, iovq) which are used to verify that objects are not being leaked. The rationale for committing this code is to ensure that it is available when it might be needed again in the future. There is no evidence that packets are being leaked at the present time. The ability to analyze the state of all calls and packets in a running system is desireable. [09:21:10] fwiw, looks fine to me, and perhaps i should implement the dump calls function for unix; but that can wait [09:32:11] --- matt has become available [09:54:24] --- Russ has become available [10:00:48] --- Simon Wilkinson has become available [10:17:36] --- dev-zero@jabber.org has become available [10:45:19] --- dev-zero@jabber.org has left [10:49:17] --- tkeiser has become available [11:10:10] --- dev-zero@jabber.org has become available [12:32:31] --- tkeiser has left [12:50:10] --- dev-zero@jabber.org has left [13:42:40] I have been examining the cause of a panic condition in rxi_PrepareSendPacket() when "len > 0". The cause is related to p->niovecs being <= 1. I believe this is a result of coding errors in both rxi_PrepareSendPacket() and rxi_FreeDataBufsTSFPQ(). [13:43:43] and rxi_FreeDataBufsNoLock() in the case where RX_ENABLE_TSFPQ is undefined. [13:45:44] rxi_FreeDataBufsXXXX accepts a parameter called 'first' which indicates the first iovec that is unneeded. That iovec and all later ones are freed and the packet's niovec value is set to 0. Except that isn't exactly true. [13:47:10] There is an assumption that all packets have a 0th iovec for the header and at least a 1st iovec for data. Therefore, rxi_FreeDataBufsXXXX() do not free the 0th or 1st and the niovecs value should in my opinion never be set to a value lower than 2. [13:48:59] I believe that rxi_FreeDataBufsXXXX() should set niovecs to MAX(2, first). I also believe that any value of first smaller than 2 should be considered an error. [13:50:19] After the return of rxi_FreeDataBufsXXXX(), rxi_PrepareSendPacket() then proceeds to overwrite the value of niovecs with the value 'i' which can be 1 if the computed value of 'len' is 0. [13:51:55] I believe that in rxi_PrepareSendPacket() that the value of 'i' after the for() loop should be set to MAX(i, 2) in order to ensure that a value of 'i' less than 2 is not passed into rxi_FreeDataBufsXXXX() and not used to set niovecs to a value lower than 2. [13:53:00] In fact, if the proposed change to the niovecs value upon exiting rxi_FreeDataBufsXXXX() is accepted, there would be no need for rxi_PrepareSendPacket() to be altering the value of niovecs at all. [13:56:58] A patch implementing this proposal can be found at /afs/athena.mit.edu/user/j/a/jaltman/Public/OpenAFS/rx_prepare_send_packet_panic-1.patch [14:51:37] --- SecureEndpoints has left: Disconnected [14:51:41] --- tkeiser has become available [14:57:39] --- tkeiser has left [15:07:22] --- SecureEndpoints has become available [15:15:54] --- matt has left [16:19:28] --- SecureEndpoints has left [16:42:12] --- SecureEndpoints has become available [20:12:23] --- edgester has become available [20:16:17] --- edgester has left