byteArena question - possible bug?

[hmsta]

// Read from UDP socket, writes slice of byte into channel.
func readFromSocket(socket *net.UDPConn, conChan chan packetType, bytesArena arena, stop chan bool, log DebugLogger) {
	for {
		b := bytesArena.Pop()
		n, addr, err := socket.ReadFromUDP(b)
		if err != nil {
			log.Debugf("DHT: readResponse error:%s\n", err)
		}
		b = b[0:n]
		if n == maxUDPPacketSize {
			log.Debugf("DHT: Warning. Received packet with len >= %d, some data may have been discarded.\n", maxUDPPacketSize)
		}
		totalReadBytes.Add(int64(n))
		if n > 0 && err == nil {
			p := packetType{b, *addr}
			select {
			case conChan <- p:
				continue
			case <-stop:
				return
			}
		}
		// Do a non-blocking read of the stop channel and stop this goroutine if the channel
		// has been closed.
		select {
		case <-stop:
			return
		default:
		}
	}
}

If I get that right you do a bytesArena.Pop() to get a pre-allocated buffer. but in case of a 0 byte package or an error you never return that buffer back, since that happens only for packets in conChan aka socketChan (dht.go:499).

my dht client recently began to randomly stopping to receiving/process any incoming packets until I restart.. so I began digging.. and that might be the reason?

[nictuku]

hey @mipak thank you for the bug report.

I didn't read other sections of the code but yes we should always return the buffer back. Want to send a patch to fix it?

I think there might be other reasons your DHT is getting stuck. Can you send a SIGHUP to the process and collect the output and share it? You can send it privately if you prefer. Thanks!