Closed masibw closed 3 years ago
(おそらく)本当の #16 の解決策です
queue.Close()の内部で以下のようにprintデバッグしたところ
queue.Close()
//Unbind and close the queue func (nfq *NFQueue) Close() { fmt.Println("Close top") C.nfq_destroy_queue(nfq.qh) fmt.Println("after nfq_destroy_queue") C.nfq_close(nfq.h) fmt.Println("after nfq_close") theTabeLock.Lock() close(nfq.packets) fmt.Println("after close packets") delete(theTable, nfq.idx) fmt.Println("after delete thetable") theTabeLock.Unlock() fmt.Println("after unlock") }
^CINFO[2020-12-13T05:20:45Z] the signal received signal=interrupt Close top
と出ました。なのでgo-netfilter-queueのC.nfq_destroy_queue(nfq.qh)が原因のようです。 しかし、この部分はC言語での実装をGoで呼び出している部分でありそのコードはこちらです。
go-netfilter-queue
C.nfq_destroy_queue(nfq.qh)
これを読み解き・改善したところでgo-netfilter-queueで改善したものを読み取るようにして自分たちで使うのはかなり難しいですし割りに合わないと思います...
強制終了に近い形になるのでメモリが解放されるかなどの懸念はありますが,現状は単にこの関数を使わないのがベストかなと思いました...
(おそらく)本当の #16 の解決策です
原因
queue.Close()
の内部で以下のようにprintデバッグしたところと出ました。なので
go-netfilter-queue
のC.nfq_destroy_queue(nfq.qh)
が原因のようです。 しかし、この部分はC言語での実装をGoで呼び出している部分でありそのコードはこちらです。これを読み解き・改善したところで
go-netfilter-queue
で改善したものを読み取るようにして自分たちで使うのはかなり難しいですし割りに合わないと思います...強制終了に近い形になるのでメモリが解放されるかなどの懸念はありますが,現状は単にこの関数を使わないのがベストかなと思いました...